[posted] Commodore C64 Emulation on a Teensy 3.6 Microcontroller

Thanks. I have never had an issue with any sketch before, and I have a few commercial products that use the IDE to generate code so I am really familiar with how it all works. The Teensy64-master.zip contains a directory called C64 that only has two files in it (C64.ino and defs.h). There is also a directory called Teensy64 which has all of the .cpp and .h files for the emulator, but no project file (which is a file that has a .ino extension). I tried combining various files and such and could not get anything to compile successfully. Since the display works, I am assuming that the joystick ports, audio port, USB port, and IEC all work as well.

The error message I get is:

:\Users\Jim\Documents\Arduino\Teensy64-master\C64\C64.ino:36:22: fatal error: Teensy64.h: No such file or directory

The compile is failing immediately because it's not finding the Teensy64.h file. I thought this was because there are only two files in the C64 directory so I copied all of the .cpp and .h files to the C64 directory with the same result.

I am using v1.8.2 of the Arduino IDE. Is that compatible?
 
Last edited:
OK, figured out the main issue. There needs to be some explaining about what is in the archive (teensy64-master.zip).

I saw above in your post: Using library Teensy64 in folder: C:\tCode\libraries\Teensy64 (legacy)

So, you need to copy JUST the Teensy64 directory to your libraries directory. The C64 directory then goes into your projects directory. The extras and examples directories can be copied anywhere.

Now I get the compile errors that deal with the changes you have stated need to be made. I will make those changes and see what happens!
 
Success! :)

For anyone pulling their hair out, follow this guide:

Make the changes to the Teensy system files as described above in post #75
Download the teensy64-master.zip from the github link and unzip the archive to a temp directory.
Copy the Teensy64 directory to your arduino libraries directory.
Copy the C64 directory to your projects directory.
Open the C64.ino project from the C64 directory (in your projects directory).
Start the compile. When finished, upload the data (if you have the auto update off).
Remove the power to the board and plug the power back in (reset does not work if you had another sketch already running on the Teensy board).

The confusion here is that normally you do not ever put files in the libraries directory unless they are in fact a library. The Teensy64 directory needs to be in the libraries directory because some files are replacing library files.
 
Last edited:
When compiled on this i7 laptop::
> IDE 1.8.5 built in ~90 seconds - clean first build on Battery and 47 seconds on AC.
> Modified beta IDE 1.9.0 built in ~60 seconds on Battery and 30 seconds on AC.

To compare resultant build results - some minor bytes of difference:

// IDE 1.8.5 build with td 1.40 released
Sketch uses 377904 bytes (36%) of program storage space. Maximum is 1048576 bytes.
Global variables use 234812 bytes (89%) of dynamic memory, leaving 27332 bytes for local variables. Maximum is 262144 bytes.

// the BETA 1.9.0 build engine with td 1.40 beta 3
Sketch uses 377904 bytes (36%) of program storage space. Maximum is 1048576 bytes.
Global variables use 234084 bytes (89%) of dynamic memory, leaving 28060 bytes for local variables. Maximum is 262144 bytes.

Both binaries still untested - but they built. I rebuilt the beta 1.9.0 version because the JAVA app had a Win 10 access popup displayed - I didn't address the first build.
 
Last edited:
The Teensy button is not RESET - but puts the Teensy into PROGRAM mode and it should allow Teensy Loader to push the code if it does not do it AUTO.

Obviously the Subset of files in TEENSY64 is a library of code. It contains custom versions of standard TeensyDuino Library code with needed modifications so the resulting build to work in the fashion needed to emulate the C64 as Frank built it.
 
I use v1.8.2 and it takes 52 seconds to compile on my desktop.

Sketch uses 377904 bytes (36%) of program storage space. Maximum is 1048576 bytes.
Global variables use 234812 bytes (89%) of dynamic memory, leaving 27332 bytes for local variables. Maximum is 262144 bytes.
 
I should try v1.8.5. After v1.6.4 the compile time more than doubled for any project. Maybe they have fixed that with v1.8.5? Parallel processing should really help. I am using a 4930K CPU @3.9GHz with all SSD drives.
 
I spent quote a bit of time this morning attempting to make a real 1541 drive work with the Teensy64. Unfortunately, it doesn't work - at least not with my board. Here is what happens:

I power up the Teensy64 with the 1541 plugged in and the screen shows the Teensy64 logo and then IEC ACCESS. The 1541 resets and C64 is up. Using the USB keyboard, I type LOAD"$",8 and press RETURN. IEC ACCESS is displayed, the drive comes on, track 18 is found and then the whole system hangs. One in about 50 attempts actually will show LOADING and then load the directory. If I power off the drive while the system is hung, I see IEC ACCESS and then the C64 shows FILE NOT FOUND and the cursor comes back. I tried several 1541's and cables, all which confirmed to work with a real C64 (sitting next to the Teensy64).

So... do you have a schematic of your board? I am assuming that the 1K pull-up resistors are partially for the IEC bus? I suppose that one of the level shifters could be bad. I have not tried a SD2IEC type device. I know the disk drive inside and out, having spent 2 decades making copying hardware and software for it, and I am about to release a true 1541 emulator called µDrive (micro-Drive) that is about 1" square in size, based on a 64MIPs dsPIC33 emulating a 6502, dual 6522s, data separator, etc. all cycle exact and supporting .g64,.nib,.d64, and .scp image files.

I have thousands of original C64 game disks that I can test once I can get the drive working in Teensy64.
 
Last edited:
I spent quote a bit of time this morning attempting to make a real 1541 drive work with the Teensy64. Unfortunately, it doesn't work - at least not with my board. Here is what happens:

I power up the Teensy64 with the 1541 plugged in and the screen shows the Teensy64 logo and then IEC ACCESS. The 1541 resets and C64 is up. Using the USB keyboard, I type LOAD"$",8 and press RETURN. IEC ACCESS is displayed, the drive comes on, track 18 is found and then the whole system hangs. One in about 50 attempts actually will show LOADING and then load the directory. If I power off the drive while the system is hung, I see IEC ACCESS and then the C64 shows FILE NOT FOUND and the cursor comes back. I tried several 1541's and cables, all which confirmed to work with a real C64 (sitting next to the Teensy64).

So... do you have a schematic of your board? I am assuming that the 1K pull-up resistors are partially for the IEC bus? I suppose that one of the level shifters could be bad. I have not tried a SD2IEC type device. I know the disk drive inside and out, having spent 2 decades making copying hardware and software for it, and I am about to release a true 1541 emulator called µDrive (micro-Drive) that is about 1" square in size, based on a 64MIPs dsPIC33 emulating a 6502, dual 6522s, data separator, etc. all cycle exact and supporting .g64,.nib,.d64, and .scp image files.

I have thousands of original C64 game disks that I can test once I can get the drive working in Teensy64.

Would be great to have a such a tester ;)
Ok, first, please make sure, everything compiled correctly: That means: F_CPU 240MHz, F_BUS 120MHz, AUDIO_BLOCK_SAMPLES=32, -O2 (no LTO or other options)
If you're unsure, please try the latest HEX-File (from GitHub)

I have a schematic - but, at the moment, the hardware is not "open" - maybe this changes one day. At the moment its not.
Testing it is easy, without schematic: There is a pinmapping on Github, and you can write a short sketch that toggles the IEC Pins (would be great if you could add that to the reprository, with a pull-request!). A voltmeter can give you the answer for Outputs. Inputs/Bidirectional lines can be tested with pinMode(x, OUTPUT_OPENDRAIN)

Since the bus works for other users (personally, I could test with a SD2IEC only), I assume no basic design problem. But ok, it is possible.

The VGA board will have different levelshifters (BSS138) and is a mixed through-hole / SMT design.
You mentioned, the board is large ? I'd be surprised if you can make it much smaller without removing connectors. And it's exactly the size of the display, so, usually, there is no point in making it smaller.

Edit: The VGA board will be a bit larger.
Edit: VIC-Code: I have some progress, some things are working better now. I can't update github at this point, because I have to complete it and want to do some tests before I can do that.
 
Last edited:
Yes, it compiles just fine and appears to work. I can make a simple test program that toggles the IEC lines high/low.

I don't see where anyone else has actually tried a real 1541. Has this been confirmed to work?

BSS138 is what I have used on everything for years!

I meant the board was large because of the connectors and their positions. I would like to make a new design that splits it into a couple of boards (all SMT) so the LCD can be mounted inside of a 1/6th scale 1701 monitor case, with the joysticks and IEC connector facing out the back of it. I doubt the LCD will handle a cable due to the SPI bus speed.

Speaking of SPI bus speed. I looked at your code for handling the display, and I notice that you use digitalread() and digitalwrite(). Are you aware that under Arduino these commands can take tens to hundreds of microseconds to complete (depending on the CPU)? It's such a problem for Arduino boards and ESP8266 modules that we have switched to getting/setting the pin by accessing the CPU directly. This eliminates the latency. I don't know how critical it is for you when changing the CS and DC pins, but every little bit of extra time helps!
 
I have two users (one in Germany) who confirmed working drives.
digitalWrite: That's used during initialization only where this does not matter. After that, there is DMA only.

Edit: the reason for the transitors was that i wanted th whole board to be through-hole and easy to solder for beginners.
 
OK, I wrote a quick test sketch. I don't know how to do anything on Github because I don't use it myself. Here is the sketch:

Code:
/* Teensy64 IEC pin test
 *  
 * November 9, 2017
 * By Jim Drew
 * 
 * Run this test and measure the voltage on each of the IEC pins.
 * You should see each pin toggle between 0v and +5v.
 * 
 */

#define PIN_RESET       25 //PTA5
#define PIN_SERIAL_ATN   4 //PTA13
#define PIN_SERIAL_CLK  26 //PTA14
#define PIN_SERIAL_DATA 27 //PTA15
#define PIN_SERIAL_SRQ 36 //PTC9

void setup() {

pinMode(PIN_RESET, OUTPUT_OPENDRAIN);
pinMode(PIN_SERIAL_ATN, OUTPUT_OPENDRAIN);
pinMode(PIN_SERIAL_CLK, OUTPUT_OPENDRAIN);
pinMode(PIN_SERIAL_DATA, OUTPUT_OPENDRAIN);
pinMode(PIN_SERIAL_SRQ, OUTPUT_OPENDRAIN);
}

void loop() {

// make all lines low
digitalWrite(PIN_RESET, LOW);
digitalWrite(PIN_SERIAL_ATN, LOW);
digitalWrite(PIN_SERIAL_CLK, LOW);
digitalWrite(PIN_SERIAL_DATA, LOW);
digitalWrite(PIN_SERIAL_SRQ, LOW);

delay(3000);  // delay 3 seconds to give even crappy VOMs time to respond

//make all lines high again
digitalWrite(PIN_RESET, HIGH);
digitalWrite(PIN_SERIAL_ATN, HIGH);
digitalWrite(PIN_SERIAL_CLK, HIGH);
digitalWrite(PIN_SERIAL_DATA, HIGH);
digitalWrite(PIN_SERIAL_SRQ, HIGH);

delay(3000);  // delay 3 seconds again and repeat!

}

This test works perfectly on my board. I can't imagine it being a NTSC vs. PAL issue since the disk drives run at the same frequency no matter what the input voltage is.

On the off chance that there was a compiling issue, I used the Teensy loader and uploaded the Teensy64_171024_PAL.hex file from Github. I got the same results. I am going to try a SD2IEC to see if that works.

Ok... SD2IEC works perfectly every single time! My 1541, 1541-II, 1571, and 1581 all have the exact same problem so I think there must be a slight timing issue with the IEC bus when using real hardware. I am using completely stock disk drives (no JiffyDOS). Let me know if I can help debug something. I have Saleae's Logic Pro 16, DSO's, etc.
 
Last edited:
Yes, that's indeed no PAL/NTSC problem. Can you please open the Aduino-Monitor and post the output?
Your sketch tests output only, but I think that's not a issue...
 
Ok... SD2IEC works perfectly every single time! My 1541, 1541-II, 1571, and 1581 all have the exact same problem so I think there must be a slight timing issue with the IEC bus. I am using completely stock disk drives (no JiffyDOS).

Hm :-( Bad news. I think I have to buy a new old drive... On the other hand, it's good enough to work with jiffydos (jiffy rom on C64-side, SD2IEC on the other), which is 25 times faster.
Is the shielding on the IEC conn. soldered (the two pins on the edge)?
 
The sketch was to determine if the level shifter is working. If the 0v/5v toggle occurs then it will also work correctly for an input. Yes, the shielding is good. I design and prototype hardware for a living, so I think my board looks pretty good. :)

I don't have the PC next to my C64 and disk drives. I will have to move some stuff around in order to be able to see results from the Arduino-Monitor.

The biggest difference between the SD2IEC and a real disk drive is the drive portion itself. It's slow, which has long delays between IEC transfers due to having to decode GCR and find the sector it is looking for. The S2DIEC doesn't have to wait up to 200ms to find a sector.
 
Output: Not needed anymore. If you say it works with Sd2IEC i'd not assume a compilation problem.
Hm, do short commands work - like the command channel?

OPEN 1,8,15:INPUT#1,E,E$,T,S:pRINT E,E$,T,S:CLOSE 1
 
I already did that earlier. It hangs (most of the time) with a 1541, and shows the error channel properly on the SD2IEC every time. I actually had it work twice in a row with a 1541 and then 10 times in a row where it hung the bus.
 
I am going to convert my JiffyDOS kernal ROM and put in place of the stock ROM (ROMS.cpp) and try that with a stock drive and a drive that has JiffyDOS in it. I am sure there is just some little timing thing going on here. JiffyDOS has a little bit different timing.

This is a pretty impressive emulator! I am interested in your VGA board too. I have a couple of extra C64C cases I got from the Kickstarter project that would be great for this along with Keyriah.

Let me know if you would like something tested. I have lots of equipment at my disposal and the disk drive internals are second nature for me. :)
 
Yes, roms.cpp is the right location. You can ignore the "patch" lines.

I've used the tool "BIN2H" (I don't remember where I downloaded it)

It is planned to support different ROMS, with easy switching between them - when I have my other - more urgent - changes working.
Hm. Would it be possible to connect a computer to the teensy ? I guess this changes the timing a tiny little bit... might explain why it worked for others ?
 
Computer? As in a PC to emulate a disk drive? Yeah, that's possible. Having more than 1 disk drive also changes the timing a little bit because of the extra pull-up resistor. I don't know how fast the transistors you are using really are. BSS138 is not available in TO-92 package, so I can't easily change the transistors to something I know works perfectly and is super fast.
 
They are quite slow. As the IEC isn't that fast, that should be OK (well, I hope).
I'd like to send you a mail, and don't have your address... can you send me a short mail to :
f (dot) boesing at gmx (dot) de
please ? Thanks..
 
Back
Top