Den Thu, 26 Jul 2018 03:55:22 +0100 skrev smf <smf@null.net>: > On 26/07/2018 02:37, Mia Magnusson wrote: > > But the VIC-II bus cycles is still read only. All other stuff is > > already there anyway. > > Being read only doesn't make it particularly easier. You argued against it being read only... > > Well, if you want to be 100% compatible except timing you need the > > CPU to write to the first 4k of the internal RAM which is 1MHz > > cycles. > > The SuperCPU has hardware that mirrors writes to internal ram > seperately from the 65816, which keeps operating at 20mhz. > > The 65816 only has to stop if another write happens to the first 4k > before the first has been mirrored. > > The SuperCPU Optimisation Modes control what range gets mirrored, all > but "none - copy everything" skips zero page and the stack. Interesting. > If you're writing SuperCPU aware code then you can interleave writes > that need to be mirrored with other calculations, so there is no > speed drop at all. > > > Well, if you can do something great, why only make it good enough > > and miss a challenge? :) > > Exactly my point. ... and the Ultimax mode would be "great", and a replica of the existing SuperCPU would just be "good enough". :) > > Well, you absolutely want it to write to the default screen ram > > place :) > > You want it to be configurable, like the SuperCPU already is. In GEOS > mode the default screen ram isn't mirrored. > > > IMHO it's a good idea to think projects through before implementing > > them. By doing something that "should probably work" as code for a > > FPGA it's easier to estimate how many pins and how much "code" the > > FPGA must have to be able to achieve the goal. It would be a bummer > > if a pin or some minor space in the FPGA is missing to be able to > > implement the ultimax mode. > > Or prototype it on a 1541 ultimate u2/u2+, just grab an open source > 65816 first. IIRC That hardware already supports vic fetches in > ultimax mode for one of the freezers. > > > Also it's not obvious which is easiest to bring up first, either > > only running the ultimax mode or only running the 65816 from C64's > > internal ram ("slow mode"). > > I am not even sure the 65816 runs from internal ram when you switch > to 1mhz mode. > > As the default screen ram can't be fetched by ultimax mode, it > doesn't seem like the first thing you'd try. well, to just bring up the hardware you don't have to get the first 4k to work. Once you have reached that stage, you can worry about the first 4k. > > (Of course only using the ultimax mode with no other > > way of the cart to communicate with the C64 won't work with existing > > programs, but might be good enough to be able to run some test > > programs to check that the hardware works as expected so far. That > > is a good step while developing hardware). > > The bringup would be easier if you get the 65816 executing from it's > own ram first and then mirror writes to the first 4k. No, as you have no way of putting any code in that ram before you start the 65816, unless you already have reached some more steps in the development process > You should build enough debugability into the hardware to help bring > it up without having to spend ages writing test code. No, it takes longer time and is more expensive to make hardware debug features than to spend short periods of time writing small pieces of test code. It is enough to write code that does something super simple like adding two numbers to each other and store the result in another position. > Once it's up then you can start adding support for vic fetching from > different places in different ways. > > > For an external cartridge on a C128, it seems like the only way for > > a SuperCPU to be compatible is to emulate the C128 MMU > I think the Z80 can write to the MMU and there is very little > information about what the original adpater actually does. Well, there is little or maybe even no reason at all to be able to switch directly between Z80 and 65816, so that won't be a problem unless you need to emulate a behavior of the existing SuperCPU that some strange software uses. > So it might not be possible to implement a completely external > solution, you might need an adapter like the original > > > interesting as except for the VDC it would probably be rather easy > > to emulate a C128 using a SuperCPU-deluxe++-replica even on a C64. > > VDC, keyboard, VIC2e test mode effects & fast IEC (although you can > hack the motherboard for that) > > You're definitely getting ahead of yourself. Did anyone actually use any of the extra keys on a C128 except for 40/80 and ASCII/CC (for the international models)? I always assumed that most C128 users were upgrading from C64 or maybe VIC-20, and therefore had learned typing on a keyboard without a numpad and had learned to use Commodores shift-cursor-key-combinations :) But anyways there were afaik no C128 software requiring the user to actually use those extra keys. So a C128 mode would work rather well also on a C64. -- (\_/) 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-27 06:01:57
Archive generated by hypermail 2.2.0.