Forum Rule: Always post complete source code & details to reproduce any issue!
Page 6 of 6 FirstFirst ... 4 5 6
Results 126 to 145 of 145

Thread: Commodore C64 Emulation on a Teensy 3.6 Microcontroller

  1. #126
    I am unable to get even a disk directory reliably with 1950 commented out. If I put it back in it works the same as it did before, so in my case it makes it worse.

    From an emulation standpoint the CIA needs to be cycle exact to the CPU, and typically with sub-cycle accuracy. So certain things like the fact that CIA timers actually start 1us after they are told to start have to be duplicated correctly. The delay in the IEC can be up to several seconds long, depending on what operation the disk drive is doing. How a IEC device works should have absolutely no affect on how the IEC bus on the C64 works. I have not looked at the relationship between the CIA emulation and the CPU emulation in the Teensy64 source code. These have to be "locked" by a common cycle clock. It's the only way to emulate this correctly.

    With my 1541 emulator (uDrive) I run the CPU instruction clock as an interrupt. When an instruction is fetched, a large lookup table jumps to the proper code to handle the instruction. The first thing that the code to handle the instruction does is to poke in a new value for the instruction clock. This would be 2us for a NOP, 4us for STA $xxxx, etc. Instructions where a page boundary is crossed will increment the clock by 1us. When done, the interrupt exits to the main loop. The CPU instruction interrupt will re-trigger when the clock time set by the last instruction look up expires. I also have the VIAs in emulations also trigger interrupts when necessary (based on the control reg). This method keeps everything synchronized. Otherwise, polling in the main loop would be required and that gets messy.
    Last edited by JimDrew; 11-15-2017 at 09:44 PM.

  2. #127
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    Try the new version from Github please. It's updated. No need for a manual code-change, no need for commenting-out that line.
    It works with the 1541 and SD2IEC. It's not tested with jiffy, at the moment. Maybe there are new problems with jiffy - we'll see...

    I guess, my English is worse than I thought. Excuse me.

  3. #128
    Ok, I will try it and get back to you!

    Good news! The change you made to CIA2 now allows me to load directories just fine. I started testing some commercial disks. Rapidlok protected disks do not work (4th and Inches, Law of the West, etc.) Likewise, Vorpal protected disks (Championship Wrestling, California Games, etc.) do not work. I tried Predator (Activision) and it goes past the protection check and the fast loader kicks in and the game works up to title screen and then hangs loading the back side of the disk. So, it seems for the most part you have the IEC working pretty well. It could be that if you are truly emulating a PAL C64, that these games don't work because they are NTSC only. Is there a chance for a NTSC version of this emulator?
    Last edited by JimDrew; 11-15-2017 at 10:04 PM.

  4. #129
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    Hi,
    NTSC is planned - at the moment the timing is PAL ! NTSC will be one of the next things, I'll do.
    Thanks for the info re: protection ! Very useful. Maybe, one day, these things will work better, too..

  5. #130
    I am sure that the problem I am having is related to the NTSC requirement. I only have a few disks that work with both NTSC and PAL (auto-detect). I will focus on those.

    Edit: yes, definitely issues with NTSC vs. PAL Also, now that you have added the exact timing fix, no IRQ loader actually works. The disk data loads but the VIC is not updated. So, games that load in the background are not changing the display data ever. This could be a NTSC/PAL thing, but I don't think so. It's like no free VIC time is available.
    Last edited by JimDrew; 11-15-2017 at 10:29 PM.

  6. #131
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    Quote Originally Posted by JimDrew View Post
    I am sure that the problem I am having is related to the NTSC requirement. I only have a few disks that work with both NTSC and PAL (auto-detect). I will focus on those.

    Edit: yes, definitely issues with NTSC vs. PAL Also, now that you have added the exact timing fix, no IRQ loader actually works. The disk data loads but the VIC is not updated. So, games that load in the background are not changing the display data ever. This could be a NTSC/PAL thing, but I don't think so. It's like no free VIC time is available.
    Yes, the VIC is paused now. Can you send me such a game, please ? Or tell me the title ?
    And, having having NTSC-only game would be great.

  7. #132
    If you had a SuperCard Pro board and 5.25" PC floppy drive you could write .scp image files to a real disk. You could also use the Zoom Floppy with your real 1541 and a PC to write .g64 image files to disk. .g64 images contain raw data including copy-protection. 720 from Mindscape, Predator from Activision, and just about everything else I tried all use a loader where the disk loads but the screen is never updated between files. There are literally thousands of NTSC games in .scp and .g64 format.

  8. #133
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    Small update regarding IEC:

    In the meantime I was able to test some hardware and got some feedback.

    Current status is:

    Teensy64 <-> 1541: no problems
    Teensy64 <-> 1541 + 1541-II: no problems
    Teensy64 <-> SD2IEC: no problems
    Teensy64 with Jiffy <-> SD2IEC: no problems
    Teensy64 with Jiffy <-> 1541 + 1541-II: no problems
    Teensy64 with Jiffy <-> 1541 + 1541-II with Jiffy: no problems

    IRQ loader: Loading works, but no audio + no image updates: This is "by design" like this, and currently intended. Maybe we can make this better, at a later stage...

    Feedback from users:

    Teensy64 <-> Ulitmate (perhaps connected to a Cevi, cable to the emulator) Transmission errors
    Teensy64 <-> 1541 Miscellaneous copy-protected disks (WARNING ONLY NTSC programs tested - can this be due to NTSC?) Does not work.

    Question: How is the timing of the Ultimate different? What exactly doesn't fit there? Which signal is slower/faster?
    Edit: Could it be a ground-loop?
    Last edited by Frank B; 11-18-2017 at 07:49 PM.

  9. #134
    The IEC timing of the 1541U2 (and U2+) is exactly the same as a real 1541. It passes all of VICE's IEC timing tests that measure sub-microsecond latency. This could be just a cabling issue.

  10. #135
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    I'll concentrate now on making my other update ready before I look at IEC again.
    Diskdrives with normal speed, and SD2IEC work good, and I think, as a first step, I should be satisfied with that for now.
    The main goal is to make as much games as possible working (- and there's work to do...). Not maximum IEC compatibility (although that would be good, too)

  11. #136
    I think I will wait on you adding NTSC support before continuing testing. I can not find a single original NTSC game that will load. Every one of them crashes at some point, which also happens when I use the .g64 image in VICE with it set for PAL mode.

  12. #137
    Junior Member
    Join Date
    Nov 2017
    Posts
    5
    I tried jumpman, space taxi, and M.U.L.E. but none worked suspect it's an ntsc issue as well. All the supplied .prgs work fine.

  13. #138
    Quote Originally Posted by gothmag View Post
    I tried jumpman, space taxi, and M.U.L.E. but none worked suspect it's an ntsc issue as well. All the supplied .prgs work fine.
    You got your boards! And parts kit(s) assembled to working - Great!

  14. #139
    Junior Member
    Join Date
    Nov 2017
    Posts
    5
    Yea, no problems, and assembly was really easy. I'm working on getting it to compile now because like another user I'm getting the ctags error. That was using Arduino 1.8.5 and teensyduino 1.40 I think so going to try versions listed. Really a cool project though and I look forward to VGA version if it works out.

  15. #140
    Quote Originally Posted by gothmag View Post
    Yea, no problems, and assembly was really easy. I'm working on getting it to compile now because like another user I'm getting the ctags error. That was using Arduino 1.8.5 and teensyduino 1.40 I think so going to try versions listed. Really a cool project though and I look forward to VGA version if it works out.
    My last build worked using IDE 1.8.5 and TD 1.40 (beta 3). I didn't catch the ctags error.

  16. #141
    Junior Member
    Join Date
    Nov 2017
    Posts
    5
    Quote Originally Posted by defragster View Post
    My last build worked using IDE 1.8.5 and TD 1.40 (beta 3). I didn't catch the ctags error.
    Interesting. OS? I was using Win10 using platform.txt, and without. I wasn't using the Arduino installer, just the zipped package. Luckily the .hex are included, even if only occasional versions I think that's a smart idea and hope Frank tries to continue those.

  17. #142
    Quote Originally Posted by gothmag View Post
    Interesting. OS? I was using Win10 using platform.txt, and without. I wasn't using the Arduino installer, just the zipped package. Luckily the .hex are included, even if only occasional versions I think that's a smart idea and hope Frank tries to continue those.
    Also Win 10. I have been doing UnZip of IDE last years - multiple installs work without conflict and got rid of odd issues I saw with IDE. Yes - I agree, working HEX is important for a baseline where the hardware/software is DYI.

    My current build didn't adjust platform.txt. Notes back a week with JimDrew show what I ( and he ) did to get a working build.

  18. #143
    Junior Member
    Join Date
    Nov 2017
    Posts
    5
    Quote Originally Posted by defragster View Post
    Also Win 10. I have been doing UnZip of IDE last years - multiple installs work without conflict and got rid of odd issues I saw with IDE. Yes - I agree, working HEX is important for a baseline where the hardware/software is DYI.

    My current build didn't adjust platform.txt. Notes back a week with JimDrew show what I ( and he ) did to get a working build.
    I'll look into it more tonight if nothing else I'll give it a try on my dev pc. It was 11 by time I had a chance to solder, 12:30am after cleaning, and had to give up around 2:30am since I wake up at 6am. I had tried to re define those in the defs header commenting out rest of stuff with no change. At least I was able to program and try the demos/couple other games.

  19. #144
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,347
    @all - can you post issues with not working software on github, please ? I want to make a list.

    I need the following information:
    - What exactly does not work ? (for example "sprite flicker", "sound problem" or "does not start" (how did you load it ? IEC/IEC+Fastloader or SD-Card)
    - NTSC / PAL ? (currently, NTSC-only games will most likely not work - for almost all are PAL-fixes available on the web)

    Please don't add demos.


    Thanks !

  20. #145
    Junior Member
    Join Date
    Nov 2017
    Posts
    5
    I am running from sd card. I got mule to work(but no joystick atm to test gameplay), space taxi says error 290 and jump man said load error, check disk.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •