[posted] Commodore C64 Emulation on a Teensy 3.6 Microcontroller

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:
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.
 
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:
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.. :)
 
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:
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.
 
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.
 
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:
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.
 
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)
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
@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 !
 
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.
 
I wanted to ask what it might take and if you think it's possible to use d64 images directly from sd card. From what I've found the majority of programs I've tried that don't use a single prg fail sooner than later, but most that are a single prg work ok, although running from sd card choplifter failed to start. I don't know the commodore well enough right now to do any work on this, although after Christmas I'd like to see what I can do to help. Would sd2iec work better for multi .prg games?
 
@gothmag
I just received my Teensy64 board and have been having a play. I've started doing a basic implementation of the D64 image format. There is a good library available called diskimage.c, though it appears to load the entire disk image into memory. I don't think this is good on a microcontroller.

As a result I have been writing my own by taking some parts of diskimage.c and following the documentation at http://unusedino.de/ec64/technical/formats/d64.html. I've done a rough implementation of loading a directory, following the directory entries from track 18/1 on. I've used the existing method in pacthes.cpp for hooking the load. In my current builds LOAD "$" returns the sdcard contents and LOAD "$IMAGE.D64" loads the directory from the image file. I've followed the existing code from Frank for the SDCard patch basically. In the image you can see the title, blocks free, file type are incorrect. I'm currently doing the BAM stuff for this.

@all: If anyone else is already doing this work, please let me know.

IMG_20171202_173256.jpg
 
Ok, so it's definitely possible. I was essentially thinking to load the image the same way but from there appear to just be a disk drive since most, but not all, of the incompatibility I've had seems to stem from multi track programs. I think mule is a good example since it runs ok up until it tries to switch from the menu to the game. I'm working on a couple hardware projects for other people right now but as soon as the prototypes are done I can start spending some time working on this. Just so you know I'm not uninterested, I just have other things I need to do right now. Are you going to put this code on github at some point?
 
@gothmag
I am happy to submit any changes to github and have Frank decide if it's clean enough. His code is pretty darn nice.
 
I don't think you are going to be able to use .d64 image files with games/demos that have custom track loaders (fast loaders). That would require low-level drive support.
 
Back
Top