Re: C64 core talk

Everything else is mirrored correctly still.  Just the addressing for the ROM and 8K RAM is decoded.  The rest of the memory map is unchanged.  This is how I was able to easily add a DPDT switch to enable/disable the decoding for the ROM and 8K RAM.  It was possible to enable/disable these individually, but that made no sense to do as they both were required by my software.

Re: C64 core talk

Does the thread "C64 & 1541 download package for Replay board (preliminary versions)" still contain the current version? Is there a newer version released anywhere?

I experience quite a few issues, especially with the floppy. Seems that .prg files work, d64 files don't. Maybe I just have a bad 1541 rom dump?

103

Re: C64 core talk

mmm it's not on the public svn is it, just the ini files.
I think Wolfgang in on this as we speak...

104

Re: C64 core talk

Yes, the download thread contains the latest -tested- versions. I pack them properly after I checked with the programs found in the compatibility list. Of course with the actual ARM FW released that time.

The 1541 implementation is independent of the C64 and is complete so far. It was not changed for quite a while. If a ROM works on a real, unmodified 1541, it will run on this core as well. Proper  D64 files (35 or 40 track = size is 174848 or 196608 byte) work w/o problem even with sw-based fastloaders like Jiffy etc. - it is by the way the same as for the VIC-20.

There can be more reasons beside bad ROM images which could cause issues:
.) D64 files with additional error info (usually 175531 byte or 197376 byte in size) - not yet supported
.) bad/damaged/incompatible sdcard (or file system) maybe check/fix on a PC helps
.) updates on the ARM firmware on the Replay board (which are not fully synchronous with cores)
.) special fastloaders (maybe an open CIA issue on the C64 side / VIA on the 1541 side - but quite unlikely)
.) D64 files with different format (very unlikely, but if it the d64 runs on an emulator, I am interested in getting one to check it out for the Replay)

It is hard to analyze a generic "don't work" issue. What does not work? No access to device 8 at all? Blinking error LED after start or at load (the red Replay LED = 1541 floppy LED, the green Replay LED = 1541 floppy inserted)? Any OSD messages? Does a directory of the floppy work? Freezes at load? No D64 working or only some are not working? To start simple, does e.g. the standard 1541 test/demo disk work? Or does the floppy load properly the intro/demo which crashes the C64 itself? Issues started after a ARM FW update?

About the SVN: I do not recommend to use the SVN version for users not interested in development, as it may have add-ons I am working on (like CRT support which has quite some impact on the whole C64 core and may still cause issues I found during testing and finally need to track down). It may even not work in case there were also some updates on the Replay framework I have not yet updated for the core itself. There is no way around that, and that is the purpose of SVN to collect changes of developers there and generate then releases out of it. Thus if one still wants to use such versions, one has to build it from there.

Update:

Just checked with the latest ARM FW: the mentioned C64 release still works fine - just checked with a dozen D64 files.

Oh, sometimes it is just because some progs need a ",8,1" to load properly from the floppy and some need a ",8" only (but this is 100% the same on a real C64+1541, just some emulators do work around this some times when drag/drop d64 files on the emu to autoload/start).

/WoS

105

Re: C64 core talk

I won't/can't distribute them, but at least I can give some links of binaries I use for testing. This is also what I found on my "real" HW I have here as reference.

Take at:
ftp://ftp.zimmers.net/pub/cbm/firmware/computers/c64/
basic.901226-01.bin
characters.901225-01.bin
kernal.901227-03.bin

and at:
ftp://ftp.zimmers.net/pub/cbm/firmware/drives/new/1541/
1541-c000.325302-01.bin
1541-e000.901229-03.bin

I also replace the kernal by "JiffyDOS_C64_6.01.bin" in the C64 and by "JiffyDOS_1541_6.00_(rebadged_5.0).bin"
on the floppy which works as well - and makes life much faster big_smile  - I bought my versions here (as I know the only/official source ?): http://store.go4retro.com/categories/Co … /JiffyDOS/

The ini files are already prepared for this filenames, for jiffy the two mentioned files need to be renamed in the ini.


Is there anyone else beside phluxx who tried to use the c64 core and it didn't work? With the VIC-20 we had a similar issue a while ago (the core did work only on my board due to a different DRAM timing my board had) but this should be fixed that time by the firmware and framework itself.

/WoS

Re: C64 core talk

Thanks for your answers.
I didn't want to give nasty "won't work" feedback, sorry. It was just that, because the core's date was February and I did not find anything released on svn (only sources), I though my core is probably outdated.

One game I tried was Katakis, which just hang in the level loader (black screen).
Also I had a strange issue with Bubble Bobble adf version (a kind of auto playing). This might very well have been because of a bad adf file.
Bubble Bobble prg worked fine.

But I also had one issue with Slap Fight (prg) which reproducable freezes after some seconds of gameplay.

Sorry that this is not a fully qualified bug report. For now I just wanted to ask for the latest version.
I can do better bug reports at a later time (might take some days). I also have a real C64 I can use as reference.

107

Re: C64 core talk

This helps, thank you! Will check out that ones. Suppose it is more an issue of the c64 than 1541...

Oh, there is one issue loading PRG files. The PRG loader just dumps the binary into the C64 memory. This is usually ok for many programs, especially code load to $8000 or $c000 or so (e.g. basic extenders, assembler, ...).

In comparison to the "real" PRG load via tape/floppy, the pointers for end of program etc. are not set properly. So if a basic program is loaded to the usual $0801 address (or at least some part is basic), any code in memory may be corrupted if it sets some variables or so. The reason is that these are put on the heap at the beginning of the free memory after the basic program - which the C64 still thinks is at the beginning ($0801).

I would need to adopt the ARM FW to update this specific end-of-program, pointer registers when the PRG file is load, but this is very C64 specific - thus I have not done it yet as I have no idea for a good "more common" solution (= useful not only for the C64)...

/WoS

108

Re: C64 core talk

Ok, checked this versions, quick status:

Bubble Bobble (my references: http://www.commodoreserver.com/PublicDi … 43771FEA0D and  http://csdb.dk/release/?id=127535):
--> no issue found, both version work (although I noticed some issues with the bass channel of the SID)...

Katakis (my reference: http://csdb.dk/release/?id=28346): C64 crash confirmed when loading the game (after intro screen) --> will check

Slap Fight (my reference: http://csdb.dk/release/?id=138141): yes, crash confirmed, as you say suddently stops after a short time --> will check

Will take a bit as I need to warm up the debugger to see where and how it crashes...

/WoS

109

Re: C64 core talk

I promise to look at the SID again ...

110

Re: C64 core talk

I'll have the transaction logger ready soon. It helps to trace CPU accesses to registers - could be useful to debug peripherals via the Replay serial, but requires an own ARM FW version as well...

Btw.: added Slap Fight and Katakis on the "not working" part of the C64 compatibility list...
http://www.fpgaarcade.com/punbb/viewtop … 2409#p2409

/WoS

Re: C64 core talk

Hi,

I played around with the newest Version in SVN. replay_c64_1541_beta_07feb2015

It's not so bad, but the Sound SID is always "catastrophic". If you know the real Thing, it is even worse then SwinSID or Emulation on PC.

Good Thing is, most things did work (graphic, disk drive, etc).

Commando.PRG: Could not reset the core with F11. It always only showed READY. and also I loaded other files or pressed RESET more often, it did not reset to the ***COMMODORE*** start Screen at all and did not load any other file with RUN. Had to load the core again.

Street Surfer: When you die, terrible Sound, also when you drink a coke, there is some noise in the Background that should not be there.

Balloonacy 2: bad Sound (filters etc)

Burning Rubber: The Sound was quiet compared to other games (but sounded good/correct), while gaming it suddenly became louder and sounded wrong then.

Chuckie Egg: No Sound when you move.

Elevator Action: Did not start at all?!?

Olympic Skier: Only half of the Sound works/does not Sound very good. Also I had a Problem twice that the LEFT in the first Level did not work (but one time, Level 1 did work, but LEFT on the Joystick always worked on e.g. Level 3). I am not 100% sure why this was Happening.

TOEDL DIOXIN (or Toedliches Dioxin): OUT OF DATA IN 18 ERROR. It's a pretty simple game no idea what was Happening there. Tried it 2 times.

Commando Arcade SE Universal: Graphic Problems and game did never start (ended with a bad graphic menu or error)

Deus Ex Machina: At least it does not have the bug where the demo knows if you use a real C64 or a Emulator (fixed on Emulator now, but there was a difference they used to see what System you use). But Sound again and many many Special effects are way off, broken or not working at all. This demo sure is the TOP of what the C64 can do (interlace, border and zoom effects etc) so it is a good test. Many games do work but this demo is the Limit and did not really work well.


I used pretty Standard Settings, all games are from my SD car of real C64, so should work there.


All in all:
most games did work, but the Sound really is something that will hold you off using that. I think it is the filter effects that are missing or way off, not even emulated. Also some strange effects that you cannot hear on a real C64 are there.

Using the menu is quite good, just why does it alsoways start at the very top of the Directory when selecting a game and you go back. e.g. you enter S Folder but you want to T, you go back, but you have to scroll down A-T again, normally you go back and you are at S, meaning you only Need to scroll down one item. I would wich a better Scrolling in the menu (not side by side but 1 by 1 item) and use of the left /right button to go a complete page or maybe left to go back (but the Folder you were in is marked, not go back to the very top). Using a Joystick also would be nice in the menu System.

Maybe you can make it compatible to FB64 file browser. (FB64, a C64 program to browse SD2IEC).

So if the Sound and menu could be improved, it would be a good Simulation. To get all the Special Demo effects will be a hard Task (impossible?).


Thank you for your work, it is amazing and I hope for updates. If you need any testing or have questions please tell me.

Give me tips on what Feedback you need to improve the core.

Thanks

Re: C64 core talk

Toedl Dioxin does work when loaded from D64 file (1541) but there is a constant noise that should not be there.

113

Re: C64 core talk

Yes, the SID implementation is a bit limited yet, Mike got a bunch of SIDs for further reverse engineering and to improve the sound (including proper filter implementations).

About the C64 hangs on keyboard reset: if the program stores the ROM signature into RAM (some games do that), the C64 may hang at boot as it can read it. On a real C64 this may also happen using a reset button short enough that the dram can keep its data, but a long reset or a power cycle destroys this signature. On the replay the RAM will never change during reset (the dram refresh is part of the framework), so once it hangs, it will always hang.

The Replay core does not know anything about the core, it just asserts the core reset signal. So there is no (true) simple way on HW side to overwrite the actual RAM signature to ensure during reset that such a ROM signature is invalidated. The reason is: if a actual ROM cartridge is loaded to RAM, the HW should not invalidate this signature automatically.

I had some thoughts to enhance the Replay ARM firmware for some specific features, but I would do this after stabilisation of framework and ARM code (Mike still tweaks here and there for the Amiga), these features should be generic enough:

- modify some memory locations upon a PRG load (to correct the end-of-program pointers like a real load via floppy/tape does)
- modify some memory locations upon a reset via Replay firmware/keyboard (OSD), but not via ini file (load a cartridge ROM, which is RAM as well on the Replay, but write-locked)

This could fix such behavior (for C64, but also other cores having a similar mechanism, including the VIC-20)

For now the only practical way is to reload the C64 ini file. This invalidates the RAM content.

/WoS

114

Re: C64 core talk

Yes - I have some improvements on hand for the SID I will get around to ASAP.

Re: C64 core talk

the SID really would be important for this project. The core is good otherwise, but the actual SID implementation really kills the fun. I know the Problem of the analog SID parts and filters, but I hope it can be fixed at least to be comparable to a SwinSID implementation.

Does the C64 Core SID support PEDDLES (analog Input of paddles and 1351 mouse)? I saw that on the Amiga core you can choose a Atari or Amiga mouse now, which is great, so it should be possible.


@WoS:
I know the programs (e.g. Popeye) also are very long in the RAM of the real C64 and may start even when switched a short time off and on again. But maybe you can find a way to reset the RAM and make a reset, so it will work always. That would be cool. The 469 board has a 10 Ohm resistor at R19 Position. I do not think this "behaviour" is used by any programs regularly? You can read here about it (German):
http://www.forum64.de/wbb3/board2-c64-a … post977133
Maybe that could help you in implementing something?

Popeye: I could start it with press of the Joystick but not on the keys "1" and "2" on the Keyboard. On the Emulator this works.

Re: C64 core talk

I have seen the same thing with any game program that deliberately pokes "CBM80" into the cartridge space ($8000).  When the C64 is reset it checked for the cartridge signatures at $8000 and $E000.  If the CBM80 is found it jumps to the cartridge location.  The only way to fix this with a real C64 is power it off long enough for the RAM contents to change.  Sometimes this means many seconds of waiting.  Just filling RAM with 00's after a reset would work great with the Replay board.  The Amiga core really needs that too, because there is also the same type of cartridge signature check that invokes a forever reboot back to the game.

Re: C64 core talk

yes, I think that would be a good Thing to try and make it more comfortable to use.

118

Re: C64 core talk

I was thinking about this.  Wolfgang, maybe we need a "fillmem" ini command to complement the file upload?
Could add hardware support in fileio for this 'suppose.

Re: C64 core talk

and something is also strange:
When I add a disk in Slot one, e.g. Amiga PinballDreams.adf and then start the C64 core, the disk drive says still PinballDreams.adf in 1541 Slot. Or via verca. Core shoud start with pre-config Slot or empty Slot but not with a wrong entry?

120

Re: C64 core talk

Yes, the last file is kept "mounted". So when reloading the ini, there is no need to mount the disk file again.

The memory init needs some careful thoughts (where, when and how to do), as one may load a real ROM file and reset the core which should still be possible. And as I said, there is the other issue with wrong pointers when directy loading PRG files to memory (especially BASIC files). I'd like to improve this as well in one shot...

/WoS

Re: C64 core talk

Yes, I understand. Keep it mounted is OK and good, but not when you load a totally different core. It does not have any effect for me yet, but it is not looking good and Needs to be polished wink

I understand the Problem with PRG loading. I will Keep it in mind when testing (but still, it is easier in my opinion to load a game with PRG from the menu instead of seaching the disk and then in the disk index etc). Thanks

122

Re: C64 core talk

The ARM does not know what is different between cores/ini, this is the idea of a generic framework. It is just another FPGA code it uploads and sets some config registers, which happens to be either a Amiga or a C64 (or whatever). Mounting files should be generic as well, handling a block device will be always quite the same for the ARM, only the interpretation of the data by the FPGA core is different.

I expect that if one loads a core by a new ini, he/she has already in mind what to do (meaning: what d64 file he wants to load). So I don't see a big problem with that, because anyway you need to select a new disk file via OSD after changing the core. If one feels to play around loading the ADF he can: the mounted file can't be read, that's it. There is nothing to polish.

It is like having a 1581 and put in an Amiga formatted disk - you simply get an error. Or having a 1541 first connected to a C64 and then you reconnect to a VIC-20 and forget to change the disk. I am quite sure even the Commodore guys didn't feel any pressure to ensure that the drive should detect all this automatically to throw the disk out or write a special error message  wink

/WoS

123

Re: C64 core talk

One problem we have is the non-removable file mounts used for HDD are not eject-able (for obvious reasons).
This can be a problem if changing from the Amiga to another core, or indeed between Amiga configurations.  Pain to power cycle.

Either I need to add an "eject all" in the menu, or I would prefer a "load target and unmount all" option, to compliment the "load target" option.

What is preferred?
/Mike

124 (edited by Kremlar 2015-11-04 11:35:11)

Re: C64 core talk

Load Target and Unmount All sounds good.

Re: C64 core talk

I agree... and fill memory with 00's to make sure we don't have a continuous reboot from cartridge signatures.