![c64 emulator mac ppc c64 emulator mac ppc](https://pulsaunatecla.files.wordpress.com/2015/05/vice_c64_emulator.jpg)
- #C64 EMULATOR MAC PPC FOR MAC OS#
- #C64 EMULATOR MAC PPC CODE#
- #C64 EMULATOR MAC PPC PC#
- #C64 EMULATOR MAC PPC SERIES#
- #C64 EMULATOR MAC PPC WINDOWS#
#C64 EMULATOR MAC PPC SERIES#
2.1 60-bit CDC 6000 series and Cyber mainframe.1.5 x86-64 platforms (64-bit PC and compatible hardware).So stay tuned for next week, when I start learning about “sync” pulses, and all other manner of wonderment, and I’ll go into a little more detail about the TAP format itself. So far, I can convert a TAP file into an AU file, but they are not playing as nicely with the real machine as I would like. I was looking at AIFF, but at this stage I think I’ll wait on that one, since anyone can convert AU files to almost any format. Plus, AU files are very Mac/Unix friendly.
![c64 emulator mac ppc c64 emulator mac ppc](https://csdb.dk/gfx/releases/177000/177104.png)
I chose the AU format, because it has a very simple header structure, unlike something like the RIFF-WAVE format, which erm… just doesn’t.
![c64 emulator mac ppc c64 emulator mac ppc](https://i.ytimg.com/vi/tOcJ0myj7yY/maxresdefault.jpg)
TTapeFile is already capable of loading, checking and performing some basic work on the TAP files, and TAUFile can now write 8/16/24/32 bit linear PCM files, which will serve as a conversion target for these tape images. I’m writing this in Object Pascal, because I think it is a wonderfully clean language which is still close enough to the actual machine / operating system to be useful.Īt this stage I have created two main classes: – TTapeFile, which represents one of these emulator tape files, and TAUFile, which represents the SUN / Next AU audio file format. With a bit of fiddling, a car-audio cassette adaptor, a CD player, it is possible to load these images back onto an original C=64 or C=128, or of course, you could take the more obvious route, and just record them onto tape, and hey presto – you have software!Īt this stage, the project is at the proof of concept stage of things… It is possible to convert these digital representations back into analog signals on tape, which is one of the jobs that Tap Dancer will perform. The tape contains a series of square wave pulses of varying frequencies, which when combined, represent the bits (1’s and 0’s) of the stored program. These tape files store a representation of a series of audio pulses, which is how Commodore machines load off tape.
#C64 EMULATOR MAC PPC FOR MAC OS#
There are already a few utilities available, but hardly any for Mac OS X, and very few that allow any kind of batch conversion of tape files. Tapdancer will be a cross platform utility for managing Commodore 64 (and other variant) tape emulation files. I’ve started this blog to document creation of Tapdancer.
#C64 EMULATOR MAC PPC WINDOWS#
A little quicker than my Windows 2000 machine (but that is a Pentium II). Long story short (no pun intended), I have tested and run tapdancer on a PowerPC Mac and it runs fine.
#C64 EMULATOR MAC PPC CODE#
Theoretically now, the same code should compile on Windows as well, and act correctly there as well. On a little endian system, this does nothing except return the value as is, but thanks to the wonders of conditional compilation, this same function will reverse the byte ordering of the LongWord on a BigEndian system.Īfter doing this, everything worked on PowerPC. So, if a value we read from a file is supposed to be a Little Endian LongWord value, we would wrap the access in endianLittleLong(). I created a unit called "Endian" which provides four functions…įunction endianLittleLong( l: longword ): longword įunction endianLittleWord( w: word ): word įunction endianBigLong( l: longword ): longword My solution was to create some functions that would compile differently based on what the target system was. The solution, at least on FreePascal are some handy defines the compiler gives you…Įither ENDIAN_LITTLE, or ENDIAN_BIG will be defined, depending on the target architecture you are compiling for. Now, if I ask the system to read a longword from a file stream, you see that this might present problems. Intel based), the LSB (least significant byte) is written first. On a Big Endian system, the most significant byte (MSB) is first in memory, and on a little endian system (ie. In that case, you need to ensure that when it compiles, it reads and writes the data to and from files in the correct way…Ī LongWord is 4 bytes. This is fine, except when you write code that is intended to be cross-platform. Pascal is a wonderfully optimized language, down to the point where it uses the byte ordering of the CPU to represent words, integers and longwords. The problem was, that I developed this on a PC, and moved the code to PowerPC based mac. Welcome to the world of endianess… where depending on whether or not you are putting some intel employees kids though college or not, or IBM kids, your lovely Pascal code might compile, but totally fail to do what it was supposed to. I transferred the code onto to our PowerPC based Mac Mini last night and it compiled first time… it was however a shame that it didn’t actually work.