On 2012-05-16, at 08:02, Baltissen, GJPAA (Ruud) wrote: > [...] > You want more Kernals, different CHARROMs and/or BASICROMs as well? > Place them on you board! Actually I want to place them on flash filesystem. Either on a flash card or built-in flash, accessible over USB. > You can program the GAL/CPLD in such a way that > the system starts up from the ROM on your board Yes, but only whenever the trigger is enabled. > [...] > Adding extra RAM in the demirrored area has its advantages: when a > certain value has been read from a reserved place, the menu program > skips itself and starts up a pre-choosen Kernal. This would have to be non-volatile as I want it to skip itself in all cases except those when menu is triggered by user's input on power-up. See also later in reply to Marko. > One more idea: connect the NMI and/or IRQ line to the CPLD and start > emulating freezers and other carts! No - there is enough of such products ready and well done. I don't see a need for another one, neither for "over-engineering" here ;-) I want something that is not there yet and keep it simple. This of course does not exclude the possibility to map-in simple ROM cart images into appropriate area. > I hope this was clear enough :) Yup, but... see below. On 2012-05-16, at 08:06, Marko Mäkelä wrote: >> I am not sure if I made myself clear. I want to be able to have a ROM replacement for the C64 (also other systems but 64 is the starting point), where I can easily manage what rom image will be made visible to the system at various addresses. It has to have a piece of own software too. The one that will display the menus for selection of the ROM images. After selecting, the images are made visible os ROM areas to the system and the system is rebooted via cold vector. > > Basically, you would need a CPLD on the daughterboard that would mimic the PLA and hijack a few addresses for itself. On power-up, the CPLD would initialize its bank selection lines so that the 6510 sees a custom on-board ROM in place of the KERNAL. This custom ROM would display the menu. Once you have selected the combination to use, the custom ROM would write to the CPLD-implemented registers to select the combination and to hide the CPLD register from the 6510 address space. Yes, this is almost exactly what I have in mind. Only plus additional trigger line so that the menu (or whatever for other systems) is being displayed only upon request. Otherwise it would pass through to normal cold boot, using the last stored on-board ROM combination. > I wrote something like this in the Vic Flash Plugin. How did you deal with the need for VIC to "see" CHAROM on the daughterboard? > It decompresses the ROM images to write-protectable on-board RAM. You might use a simple EPROM for all images, or make some effort to load the ROM images from a SD card. But would it be handy to open the case to switch SD cards? I see this as flash filesystem. Being it either a removable card or a built-in flash storage, accessible over USB. In both cases either slot or socket would have to be "somewhere". I would prefer to have it accessible w/o opening the case, of course. Since the choice of ROMs has to be non-volatile, I imagine e. g. that the chosen images get copied over to a dedicated flash / EEPROM area and are served from there, independent of e. g. the SD card being present or not. > By the way, if you go the CPLD route, why not pick a bigger chip that could implement a co-processor or a REU clone or whatever? Again - because those exist and if somebody is to make this product, then it has to be a short project rather than one more "neverending story". Besides, I am a believer in "first make it work, then optimise (or add more features)" paradigm.. Now to the second part - both of you Ruud and Marko got the idea and know right away how to do it from the technical POV but this is also the point where I don't feel like I could do it myself. At least not in a reasonable time. Therefore if someone would be willing to make it according to my specs, I am ready not only to buy it right away but alternatively I can also fund some development / return costs, ... And of course the eternal hall of fame awaits for those who dare.. :-) -- SD! Message was sent through the cbm-hackers mailing listReceived on 2012-05-18 13:00:05
Archive generated by hypermail 2.2.0.