Re: MMU prototyping

From: Nejat Dilek <imruon_at_gmail.com>
Date: Wed, 23 May 2018 18:50:13 +0300
Message-ID: <CAP5r8NRBK9on=dmg9OTQQhLyJN40BM0pJcBcbvSw9fsts+TKYA@mail.gmail.com>
On Wed, May 23, 2018 at 2:41 AM, Jim Brain <brain@jbrain.com> wrote:
> On 5/22/2018 4:07 PM, Nejat Dilek wrote:
>>
>> Nice project!
>>
>> Does this also use hacks around the PLA like EasyFlash?
>
> I guess it depends on what one defines as a "hack".  This unit simply
> engages the GAME line anytime a memory access that should be outside the C64
> is requested.  I think that is standard behavior.
>

"Hack" in my sentence was not used in a devaluing context.
Specifically in this context one need a much higher clock speed and/or
rely on specific timing properties. (Like the kernal replacement in
newer easy flash incarnations. )

Not a direct analogy but it's like shifting the gear in a car
continuously between say 2 and 3 because it results in better fuel
consumption. Proper implementation would be to change the gear
mechanism that makes this more natural.

In the same way, a proper (I'm just using this term to explain how I
define the "hack") solution to the problem might be changing the PLA
to a more capable one  instead of fooling it.

Anyway, my actual curiosity was around the technical side actually.
Easyflash employs a much broad "hack" to accomplish it's kernal
replacement goal. So I understand this is much simpler to achieve.
Much less obtrusive "hack" :)


>>
>> Why not use pages of 8 / 16Ks too?
>
> As I looked at the Ultimax map, all pages except for 0-fff and d000-dfff
> were movable.  Doing 8kB means one needs to map in a bank, but can't use all
> of it.  It seemed cleaner to map on 4kB boundaries.  One can handle 8 or
> 16kB by simply using 2 or 4 consecutive banks.
>>

If VIC will readily access the switched ram, it would be imho wiser to
keep the ability of mapping 16k with just a single paging access. It
would be useful for stuff like video playing.


>>
>> I had once a simpler ram extension idea employing the same concept in
>> below old project which was published in the Transactor. (But of
>> course with a bigger 512K or 1MB sram)
>
> Well, my solution uses a 512kB RAM, and will support up to 256MB.

Well static ram is expensive and the large sizes are much more
expensive and not easy to handle coming in bga packages.
The biggest alternative on Mouser is 16Mx8 and it is a 3.6V part, ~€10 a piece.

>>
>> It would be nifty to have some external storage mechanism in the cart
>> too. It would be really cumbersome to load content into this
>> additional ram from the disk drive.
>
> True, and that's a nice thing to consider.  I mainly want to understand if
> anyone sees value in the MMU or the memory before I pursue more work (I
> built the board for other reasons, but decided to implement this
> functionality while I was testing the board asembly).
>
>
> --
> Jim Brain

It's a bit hard to evaluate beforehand. 90% of the crowd cares about
playing with existing stuff, quite lot of people developing stuff in
the remaining 10% mostly prefer the stock hardware.
Unless a specific software/game title unleashes the power of such
hardware the probability of it being mainstream  is very limited.

The price is of course a big determining factor too,

Regards,

Nejat
Received on 2018-05-23 18:00:48

Archive generated by hypermail 2.2.0.