16-bit C64/128?
in [Commodore]
|
From: christianlott1 on 13 Apr 2008 19:56 Let me again state how much I like this idea. Three ideas based on this - are they feasible? 1) VIC2 - True hardware scrolling. 2) 6510 - Selectively re-implementing some opcodes (allowing all other opcodes pass-thru to real processor). These suggestions are 'single-feature' meaning the original chip is still being used for the most part. 3) Last question is about the VIC2 stunning the 6510. Could the VIC2 be effectively stopped from doing this - maybe by some kind of write- thru or mirror ram on the daughter board? With your comment about a 16 or 32 bit processor - it makes me think maybe migrating these chips to a 16 bit bus board.... Which is WAY off target here, so I'll stop. I think it would be arbitrarily limiting though if this daughter board did not itself have a pass thru bus (for a real alternate processor). But I understand I may need just make do with a SPI connection. More questions: What's the price range of something like this? Should there be 2 SPI connections on each board, giving the ability to daisy chain a SPI bus 'behind the scenes' to other daughter boards? Which FPGA? What software? Would it be *possible* to emulate the C65? :) Would this new hardware strain the power system? How's the uIEC coming? Christian
From: BruceMcF on 13 Apr 2008 20:37 On Apr 13, 7:56 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > Let me again state how much I like this idea. I also think its a great idea. That Jim, he's a real ... .... oh, wait, never mind. > Three ideas based on this - are they feasible? > 1) VIC2 - True hardware scrolling. Is this in a bitmap inside the chip, or a normal VIC-II bitmap? Inside the chip, the issue is how much blockram the FPGA has ... outside, its whether there is enough memory bandwidth. Of course, the VIC has to have enough bandwidth to read each bit in the bitmap multiple times a second, so given 8K internal/onboard RAM, I guess in hardware scroll mode it could store the screen as it reads it, and then just read the new lower/upper row and/or left/right column to do the scroll. > 2) 6510 - Selectively re-implementing some opcodes (allowing all other > opcodes pass-thru to real processor). This is the one where I'm thinking a second piece of hardware is needed, that the 6510 can plug into and that plugs into the 6510 socket. Now, the 6510 is not a static design, so it does need to "keep moving", as it were, but maybe the board could, for instance, feed a dummy opcode to the real 6510, of the right kind to keep the process working and the instruction register in sync. The real tricky thing is how to get the status register bits set up correctly? More *straightforward* by far (easier, I dunno, ask one of them hardware guys) to start with a 6510 softcore in an FPGA replacing the 6510 altogether, and then do the selective re-implementation of the op- code in that. Jim's idea is that you plug the FPGA into the socket of the part you want to play with, and the rest is the familiar C64. Its kind of like the hardware equivalent of the Zsystem in CP/M, where an enhanced but compatible BDOS and enhanced but compatible CCP with expanded capabilities were plugged into place, and the BIOS was normally customized anyway, to give a "CP/M" machine that did not have anything from CP/M left in it except the compatibility. This could end up the same way ... when you get to a C64 that is all FPGA modules pretending to be chips, you have a C64 that, in hardware terms, has almost nothing left except the compatibility. > These suggestions are 'single-feature' meaning the original chip is > still being used for the most part. The most straightforward, though, is not to use the original chip. The point is that if the whole C64 can be put into an FPGA, as in the C64DTV, then an individual working on an upwardly compatible version of an individual chip could quite possibly make quite some headway ... and if its a common part that multiple people are using, then it starts to pick up the "project" scenario where the best debugger is multiple eyeballs hooked up to different brains all looking at the same design. > 3) Last question is about the VIC2 stunning the 6510. Could the VIC2 > be effectively stopped from doing this - maybe by some kind of write- > thru or mirror ram on the daughter board? Don't forget that the VIC does the DRAM refresh. Replace the DRAM with static RAM and you have lots of opportunities that were not available in the early 1980's. > With your comment about a 16 or 32 bit processor - it makes me think > maybe migrating these chips to a 16 bit bus board.... > Which is WAY off target here, so I'll stop. Now *that's* not Jim Brain, that's my brain (lower case b) ... sputtering and clattering along its same old habitual ruts. But, yes, if the designs work, then by the nature of the beast, they can be migrated to all sorts of different settings. A VIC-2020 and SID-3D in a CP/M system by someone with a bug to see how far the GSX can really be pushed. > I think it would be arbitrarily limiting though if this daughter board > did not itself have a pass thru bus (for a real alternate processor). > But I understand I may need just make do with a SPI connection. > More questions: > What's the price range of something like this? This depends on the size of the market. The normal way to test the waters for something like this is to get is fabbed on spec in a small order, and if it keeps getting ordered, and especially if building units using these chips start getting picked up by CS & EE programs, maybe a supply house picks up the design. Starter kits from Xilinx range from $150 on up for the starter kit with their Spartan-3 family, and $50 on up for the starter kit for their CPLD family ... I get the impression this would be substantially less than that, even in a small run on spec. To get a baseline, just browsing a little bit now, I am seeing the Xilinx Spartan-3 FPGA's listing in quantity-1 in the $10-$20 range. > Should there be 2 SPI connections on each board, giving the ability to > daisy chain a SPI bus 'behind the scenes' to other daughter boards? That depends on whether a device has to play both controller and device roles. If there is one controller and multiple devices, the SPI bus does not need daisychaining, just one additional wire for each device controlled (for a multiple device on option) or n wires to control (2^n)-1 devices, if a device number system is used. > Which FPGA? What software? > Would it be *possible* to emulate the C65? :) Possible physically? Possible to get enough people interested to do it? > Would this new hardware strain the power system? No, the boards would be lower power than the 1980's technology chips they are replacing. > How's the uIEC coming? Don't distract him when he's on a roll ;)
From: christianlott1 on 13 Apr 2008 21:55 On Apr 13, 7:37 pm, BruceMcF <agil...(a)netscape.net> wrote: > On Apr 13, 7:56 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > > With your comment about a 16 or 32 bit processor - it makes me think > > maybe migrating these chips to a 16 bit bus board.... > > Which is WAY off target here, so I'll stop. > > Now *that's* not Jim Brain, that's my brain (lower case b) ... > sputtering and clattering along its same old habitual ruts. But, yes, > if the designs work, then by the nature of the beast, they can be > migrated to all sorts of different settings. A VIC-2020 and SID-3D in > a CP/M system by someone with a bug to see how far the GSX can really > be pushed. GSX - graphic system extension? I did a little research on this a few weeks ago. All I could come up with is NCAR graphics/NCL - http://www.ncl.ucar.edu/index.shtml check out the gallery. I got to this by looking for GKS then DISSPLA. The lineage seems to go from GSX to GKS to DISSPLA to NCL (I guess). the system is downright beautiful IMO. I don't know what kind of video adjustments you could do on the fpga but I doubt you could come close to all that. But if there was a pass thru on the daughterboard that made all the fpga lines available a very large video system could be built up. Or we could listen to Phuque and wait for the Atom.
From: Jim Brain on 13 Apr 2008 23:13 BruceMcF wrote: > The DTV is not a social computing device ... you cannot, out of the > box, download a newly patched game, plug something into the DTV, and > run it, nor plug two together and play against someone else. Since using program 'X' can be accomplished today on portable HW like the PSP or some cellphones, I don't believe it has anything to do with running program 'X'. I think it has more to do with offering a device that provides the expansion ports of the 64/128, something an emulator cannot provide at any price. Jim
From: Jim Brain on 13 Apr 2008 23:21
christianlott1 wrote: > 3) Last question is about the VIC2 stunning the 6510. Could the VIC2 > be effectively stopped from doing this - maybe by some kind of write- > thru or mirror ram on the daughter board? Maybe. One could provide dual port access to RAM in an FPGA. > I think it would be arbitrarily limiting though if this daughter board > did not itself have a pass thru bus (for a real alternate processor). > But I understand I may need just make do with a SPI connection. I agree it's not ideal. On the other hand, if one tries to put the kitchen sink into such a card, it ends up like so many other ideas, great on paper but never implemented. > What's the price range of something like this? The boards with just an FPGA should cost little more than the FPGA. The main one might cost a bit more. SO, go check out FPGA prices for a good estimate. > Should there be 2 SPI connections on each board, giving the ability to > daisy chain a SPI bus 'behind the scenes' to other daughter boards? I would be OK providing a bit of user defined IO on the board, but I think making more specific items just limits their usage. > Which FPGA? What software? I would assume Altera or Xilinx, as they have free design SW and do seem to be heavily adopted. > > Would it be *possible* to emulate the C65? :) Anything is possible. > Would this new hardware strain the power system? It would add trivial additional power draw. > How's the uIEC coming? I'll post that in a new message, since you brought it up. Jim |