Thank you Mia, I didn't know much about the the Max or Ultimax model. The information that you shared and ideas, is great in order to establish the possibilties of dealing with the RAM resources. I Will check the _game technique. Thanks, Luis Vela dsp8bit El jue., 19 de jul. de 2018 6:37 PM, Mia Magnusson <mia@plea.se> escribió: > Den Wed, 18 Jul 2018 13:57:48 -0500 skrev Luis Rene Vela Garcia > <lrvg1010@gmail.com>: > > Hi Guys, > > Welcome :) > > I'm not totally sure exact what information you are looking for. > > But in general there are two strategies here. One needs to be used and > the other can greatly speed up things. > > As Ruuds stuff about the CP/M cartridge says, the C64 has a mode where > an external CPU can access the C64's internal memory. > > But you can also do it the other way around, let the C64 access > external memory. This is called the "Max" or "Ultimax" mode. > > The intention of the mode is to provide compatibility with the > Max/Ultimax gamle machine which was like a C64 but almost only for game > playing, containing a small amount of static ram and partially the I/O > a C64 has, but otherwise you had to provide a cartridge with rom and in > some cases (the Basic programming language cartridge) also ram). > > But in practise you can assert _GAME at any time which disables most of > the C64 internal memory and let you drive the data bus in the cartridge > port when the C64 does a read operation. This way you can provide > external memory for the VIC-II video chip. The exception is the first > part of RAM (iirc 4k) which were actual ram on a Max/Ultimax and thus > the internal C64 memory is always enabled at those addresses. Also the > I/O areas might not be possible to disable (but I'm not sure here). > > For a 65816 accelerator I think you should start as Ruud suggest by > running the 65816 at 1MHz and let it use the C64's internal memory for > the first 64k of address space. > > Then I actually suggest using a PLL driven oscillator and sync it to > the C64 clock frequency as it makes timing easier. > > The next step would be to add ram which at first is enabled for the > addresses above 64k. > > Here comes a nice trick: The next step would be to put the C64 in > Max/Ultimax mode and let the C64 VIC-II chip read from the faster > memory in the 65816. From the point where VIC-II supplies a valid > address to the point it samples the bus you are free to do a faster > read cycle of your memory and latch the read data until the VIC-II > actually samples the data bus. That way a VIC-II read cycle will only > take as short time as the memory can provide data at, and not a full > half of a 1MHz cycle. > > Unfortunitely this won't work for the first 4k. You can speed up things > a lot by writing both to the internal C64 memory and the faster > expansion memory, but only read from the faster memory. There is > nothing but the CPU that can alter memory contents so that won't cause > any incompatibly. > > The I/O address space must of course be directed directly to the > existing C64 hardware. > > A tricky part is the 6510 buildt-in I/O port at address 0/1. The only > way to actually read/write to that port is to run code in the 6510 > itself. However that port controls memory mapping and some pins of the > cassette interface. If we assume the 65816 won't use the cassette > interface (but switch to 6510 mode as the cassette port anyway needs > compatible timing) the memory mappings can be simulated by adding a > port at address 0/1 on the 65816 and map in/out write protected parts > of memory that contains copies of the C64 ROM's, and also map in/out > access to the original C64 hardware for the I/O space. That way almost > all C64 software will run fine, and you can also soft load basic/kernal > rom images. > > I'm not sure how JiffyDOS works on a SuperCPU, but in general JiffyDOS > is a replacement kernal so you'd just need to use another image for > Kernal. If you want to, you could make your hardware able to show it's > ram to the 6510 CPU (using the _GAME technique) making it possible to > let the 6510 use a JiffyDOS image instead of the standard kernal. > > Btw even thogh JiffyDOS is a great improvement, as the 65816 mode won't > be compatible with existing timing critical software (like games and > demos) anyways, I suggest adding a SD card interface to your hardware, > and space for some kind of ROM making it possible to load/save to the > SD card directly. That would win over any JiffyDOS solution speedwise, > while those wanting a 100% compatible drive can use either an existing > 1541 or a 1541 Ultimate, even together with your hardware. > > > > -- > (\_/) Copy the bunny to your mails to help > (O.o) him achieve world domination. > (> <) Come join the dark side. > /_|_\ We have cookies. > >Received on 2018-07-20 15:01:45
Archive generated by hypermail 2.2.0.