[1]The C64 Community Loading... This site is best viewed in a modern browser with JavaScript enabled. Cartridge support tobiasluethi Will there be a cartridge port on the full size for the original cartridges? -------------------------------------------------------------------------- Trinket All signs point to this being a software emulation device, so I'd say no. -------------------------------------------------------------------------- tobiasluethi [2]Trinket I'm pretty sure I read this once at the very beginning of this project. But at the end it only matters what they decide... -------------------------------------------------------------------------- Trinket [3]tobiasluethi Yeah, iirc it was supposed to be a breakout header to a cart edge slot or something. Honestly, that idea from a technical perspective is complete ... horse apples, as were a lot of the tech claims in the beginning. There was much groaning and chortling going on in the community at that time. -------------------------------------------------------------------------- ReflectedLightEntertainment For a lot of reasons, doing a real expansion port would not work properly without some very serious and I mean VERY SERIOUS level electronics engineering. Basically, they will have to do a new revision of the C64DTV core or obtain rights to use the FPGA core designs in the Turbo Chameleon project and adapt it. Basically, do what Jens Schoenfeld and what also Gideon Zweijter is doing (with the Ultimate 64). Here's why? The expansion port on the C64 isn't just a game rom port. While doing ROM maybe somewhat easy by using some device interface that reads the ROM and mirrors it onto the hard drive (or flash drive medium used by the emulator) but once you start opening the door for that, you are opening the doors for people who will likely attempt to insert other devices such as RAM expansion units which may try to DMA into the system memory, or devices like CPU accelerators units such as the SuperCPU, RAM Link and other devices including Z80 cartridges that were made for CP/M support. These devices involves other signal lines and essentially a bus mastering system. So in effect, it may cause some serious problems. For numerous reasons I can not effectively communicate clearly, in short, there are many factors that can go wrong and cause a system wide crash if not possible damage to the main computer and/or the attached plugin devices or even the interfacing mechanism. The closest thing to the cartridge port on the C64 that you may recognize on IBM PC Compatibles in the past is the old ISA slot. When devices are attached on the cartridge port, they are physically mapped into memory at fixed locations. So is ISA cards on old MS-DOS/early Windows based IBM PC & compatibles. Some plugin devices actually bus masters under DMA to the RAM on the computer. Another issue is if anything in the emulation is off by enough "1 MHz" cycles or even "System Bus cycles" on the emulation system (which is 14.31818 MHZ NTSC, or 17.734475 MHz PAL) or if anything is tied into the DOT clock and synchronized to it (as it is on the original C64).... but if the emulator is off, things can unravel. Remember, the hardware devices are fairly fixed, especially the original hardware accessories. These devices worked quite consistently. These clocks are extremely stable compared to the variability that is found in modern OSs like Windows which may or may not provide you with stability of emulation to less than +/- 25ns instability variance. Unless emulation is rock solid to say.... +/- 25ns stability tolerance operational stability, I would probably not recommend such. My suggestion is stability of less than 1/2 the clock cycle of the Y1 crystal frequency so that everything operates in perfect clockwork You'll basically need to match the clock conditions as found on the original systems and probably phase locked. Some devices may by nature of electronic engineering design be able to ride through clock cycle variation of +/- 10 microseconds or greater clock deviation. Have you not noticed on VICE on Windows (for example) the emulation speed may vary as much as say 2-3%. Usually at about 1% variation due to other activities on the computer and sometimes other issues. The system doesn't always keep an exact consistent 100% emulation when it can run between 95% to 105% and you may see skippy operations. If anything like with an attached expansion port devices that relies on a consistent synchronous clock condition, things may result in problems. In a bad case, it may crash or lock up the system. These devices were meant to operate a synchronous relationship. In real hardware, +/- 2-3% tolerance in clock stability is probably unacceptable. Maximum instability of the emulation environment should not result in the emulation of the Y1 system clock to be off by more than 25ns. I don't think that can be achieved effectively on software emulation. It might not break the games but hardware accessories on the expansion port may or may not be so tolerant. We are talking about a world of issues that can crop up and no one has done this yet. If it haven't been achieved in the Commodore community already, it is probably not possible yet. The Commodore community currently has some of the very best and most qualified electronics and programmable logic engineers with acute familiarity of the very nuances of the various models of Commodore computers and their various revisions. We have a community of people that collectively knows more about the C64 than even Jeri Ellsworth or anyone or ALL the individuals working for Retro Games Ltd. including the owner(s) of Retro Games Ltd. This is not meant as an insult but a fact. This community has 30+ years of studies by 100s of individuals with advance education and experience in hardware and software engineering. These individuals are the world's premier experts of the Commodore system. Collectively, we even have Bil Herd and other people who contributed to that body of knowledge. If we haven't figured out a stable way to do that with Windows or most other modern systems with modern multitasking operating systems, there s probably a good reason and it is unlikely that someone hiring an electronics engineer with very little to no experience with hardware engineering for the Commodore hardware platform is going to just some up with a solution that adheres to a 100% or at least 99.9% compatibility with every known C64 expansion port device. Retro Games Ltd. has not really involved or consulted these people of the Commodore community on an intensive level. Without doing so, it would be very much impossible for them to do so. -------------------------------------------------------------------------- ReflectedLightEntertainment In short, it would be impossible for a fully compatible C64 expansion port. While you can make compatibility for pure ROM cartridges. It would be more trouble for something that used the C64 expansion port in a more sophisticated way. In these more advance devices, I see the likelihood of a cascade of problems. If instability of the emulator causes jitters in the operation of the emulation environment causing deviation of more than +/- 0.5 Clock Cycles of any of the clock lines from Y1 Crystal clock to Dot Clock to Phi 2 system clock. Maximum jitter should be less than 1/2 CLK Cycle on all of the clocks because there is a relationship. That's my opinion for having a stable operating environment so much so that it is literally cycle-exact at all times regardless of any other programs operating in the background on whatever OS it is running on. -------------------------------------------------------------------------- cb3rob [4]ReflectedLightEntertainment I don't think this is an emulator tho. i think it's an fpga. but the expansion port would take up a lot of pins and external drivers. -------------------------------------------------------------------------- cb3rob [5]ReflectedLightEntertainment as for the 'very serious engineering'... come on, the whole thing, just like any other 8 bit micro out there, was developed in a couple of months back in 1977 when they didn't have proper CAD programs, no proper displays capable of clearly displaying larger schematics, no 2d cnc pcb mills, etc. and yet they managed to put them together in a matter of days to weeks using wire-wrap and large pieces of paper. i'm confident adding a user port -can- be done. just that it would probably take more out of the profit margin than the rest of the design put together and also significantly increase power use and rf emissions. (just having your address and data bus poke out of the back of the system without any type of cover may have been acceptable in 1981 but it most likely isn't today). -------------------------------------------------------------------------- cb3rob for actual game cartridges which are really just rom and nothing else you can just make a ripper device which turns them into relocating prgs.. as for anything else.. let's just say that at the very least it would be a whole lot of voltage level adjustment between whatever this new thing uses and ttl and cmos compatibility in the original cartridges. also an old ttl based cartridge would probably suck more amperes out of the power supply than the whole new computer does anyway. IF it's fpga and has somewhat accurate re-creations of the original logic (from what i understand the original drawings for the sid wafer are missing in action, although there are quite a few sid reproductions based on microcontrollers that achieve the same task) it should be possible. but it would increase the pin count on the fpga(s) and require a whole lot of external voltage regulation and adjustment. would be nice if they would be a bit more clear on exactly -what- they intend to start selling before advertising it [6]:P if it's just an emulator running on some arm core in a 'funny shaped box or the actual real thing in fpga logic. also exactly for how long they plan to keep offering this product. as before new development for this platform takes place, it would be practical to know wether this time around it's actually gonna stay on the market or just be available for a couple of weeks. there is plenty of space in the market for a games platform with well documented hardware, none of those crappy crypto keys and 'licensing schemes' for 'developers' such as nintendo and sony do (ain't noone gonna code for that shit, having to 'ask permission' and bribe people to distribute your own software. lol), and it doesn't even have to be technically advanced.. but it does need to guarantee it's own availability for some time to come. now, as far as i'm concerned, ethernet support was a requirement starting 1985 and lasting to this day, so it would be nice if they at the very least dropped in an enc28j60 or something. people do want some means of doing multiplayer nowadays. even plenty of ethernet carts out there for -actual- c64s. -------------------------------------------------------------------------- Trinket What reason do you have for thinking it's an FPGA? Every single photo of the board where the chips were discernible had a big ol' ARM chip dominating it and nothing remotely FPGA-like. Also, wrapping a front end UI around the emulator and doing things like savestates (though I don't remember if those are supported) would be a lot harder with a FPGA than with software emulation. Plus a FPGA would make the hardware more expensive and more power hungry. As for the development of the original chips, yes they were done fast, but MOS and CBM had a lot of tools and processes that were better than the industry standard at the time, which is why they were able to put cheap, good computers out. Plus, even though they were created relatively quickly, they're basically a bunch of hacks bolted together and have strange edge case effects. That's very difficult to replicate exactly, and tons of software rely on the quirks of the hardware. If you were only to implement hardware based on published specs of the chips, you would not end up with a fully C64-compatible device. -------------------------------------------------------------------------- spannernick1 The cartridge port can read the kernal,cause I have a Easy Flash 3 in my c64 and I can run different c64 kernels like JiffyDOS and EXOS V3 and V4,some Cartridge games will not work ,if they can't read the kernal. -------------------------------------------------------------------------- spannernick1 I know a way of how they cause do cartridges,they could make them like sd cards but can only be used on TheC64,the card could have a crt on it and TheC64 reads it and run the game before boot up.But the old c64 cartridges would not be compatible. -------------------------------------------------------------------------- References Visible links 1. https://community.thec64.com/ 2. https://community.thec64.com/d/46/2 3. https://community.thec64.com/d/46/3 4. https://community.thec64.com/d/46/5 5. https://community.thec64.com/d/46/5