On Wed, 11 Apr 2001, Ruud Baltissen wrote: > > However, feel welcome to use d700 > > Unfortunally I need 256 bytes for the window PLUS some bytes for I/O. An > other solution is decrease the window to 128 bytes but I realy dislike that. I dont know of ANY I/O boards that use more than 32 bytes actually. I'd feel rather comfy iwht 128 bytes if we have dma-to-c64 in the future. > > > Having said that, it is possible that all > > non-standard writes in the I/O region will > > be lost by the SCPU, and so only DE00-DFFF > > are only valid use by this and other projects. > > My first reaction is: "that's the SCPUs problem, not mine!" but that sounds > a little bit selfish. Then you can kiss most people g'bye. There are quite a few people I know who believe the SCPU needs something better than the c-64's bus. Even if its hiding behind some IO window. I'd rather collaborate and make a design the two of us can agree on, so I dont end up going with my own, incompatible design because someoen was too pigheaded to think compatibility in the modern world of commodore. (no flsmes intended) > I have given a thought to this window problem and the only solution I can > think of is cart which disables the window in favour of carts using this > area. But this means extra hardware as these carts are in chain and _NOT_ > parallel. And I also know some carts which use BOTH IOx-lines and therefor > cannot be used in combination with any other cart at all (like FC3). Grow up. Throw the FC3 out the window like I did. ;) Further, if you choose to use kernal carts, and not antying more compatible (i.e. JDOS, or the stock kernal), you're just plain asking for trouble. > I prefer the VIC-II de-mirroring solution: easy, quick and dirty :) I prefer to stay outside the c-64. True, the I'O decoding REALLY sucks, but not everyone can handle internally modifying their c-64. If we can stay outside, and work from the cart port, we can get much more support from the scene. > Flash idea: what about demirroring a CIA and using $D7xx? the CIA is at dc00 and dd00. D700? look at the top of the file. ;) D700, however, only works from the cart port on a 128, and you'll need separate decoding hardware for it. Mind you, if we build our own DMAC for the c64 side, we'll have all 16 address bits routed into the device already. Its not too hard to compare 8 of 'em. To use D700 on a stock c-64, you'll have to decode the SID. This is, again, an internal mod ;) I suppose it wouldnt be -impossible- to build a small card like the MMUboard for the scpu, which disbles the sid at d5/d6/d700 and use those ranges while not on the c128.. In fact, tis not a terrible idea to use it on a 128 either, since it can deliver d700 to us. Personally, I dont know how widely used d700 is. I'm aware Nate has his second sid there.. Is anyone else using it? - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.