On Thu, 12 Apr 101 email@example.com wrote: > Hallo jbevren, > > If I may ask, what is your real name? > > > > 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. > > Then I have news for you: If you want DMA, you need that minimum 256 byte > window. As I already said, I intend to use the 8237. It drives A0..7 > directly, A8..15 is driven thru a latch. Driving A7 thru a latch as well > only complicates things. Um, no, you don tneed the wide window ;) The 8237 register set is NOT more than 32 bytes, and DMA has nothing to do with I/O windows ;) > > > Grow up. Throw the FC3 out the window like I did. ;) > > I hardly use it but being a techie I opened it and noticed this behaviour. > And as a techie I dislike this solution. It had been much more nicer to use > an extra decoder so one could combine this cart with others. Its like the (similarly) unfriendly epyx fastload cart I sometimes use on my non-scpu system. ;) > > > This is, again, an internal mod ;) > > You cannot blame me using a hack because others messed up first. Even > Commodore is to blame because the REU needs less then 16 bytes but due to > mirroring, no one else can use (a part of) the other 240 bytes :( I dont, really. I woudl LOVE to re-do the internal I/O decoding. Bogax and I are working on a new form factor for the c64 board, which will have cleanly decoded I/O. That's another topic, however, so I wont get into it here > > > I'd rather collaborate and make a design the two of us can agree on > > ... > > If we can stay outside, and work from the cart port, we can get much more > > support from the scene. > > As already mentioned, my design will use the the I/O-lines in the first > place. And you may tell me what IO-line to use for what part :) > The connection is made using two jumpers. If one intends to use other base > addresses, (s)he only needs to connect these pins to the outputs of the > used decoders. > Until now all my software is freeware, including the sources. This enables > one to compile its own version. > > But if someone decides to write non-public SW for the standard IO-lines, > then the above person simply has bad luck :( That someone is plain silly ;) > > How does this sound to you? Hmz. Sounds good. Have you read my post about the pcb under the sid? > > > the CIA is at dc00 and dd00. D700? look at the top of the file. ;) > > I understand you would agree on $D7xx as well. Then this could be my 256 > byte window. Then I need another 8 bytes for the I/O. Use an extra decoder > with one of the CIA's et voila, I have my extra bytes. > > Then I have a question: is there a list where you can see which I/O-cart > use which address? > And then for the SCPU-users: what I/O-addresses does the SCPU use > (including possible mirroring)? > > Groetjes, Ruud > > http://Ruud.C64.org/ > > > > - > This message was sent through the cbm-hackers mailing list. > To unsubscribe: echo unsubscribe | mail firstname.lastname@example.org. > - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail email@example.com.
Archive generated by hypermail 2.1.1.