Re: MAX Machine PLA equations

From: André Fachat <afachat_at_gmx.de>
Date: Sat, 06 Aug 2016 19:09:41 +0200
Message-ID: <15660d4e808.2813.b4d1f2b66006003a6acd9b1a7b71c3b1@gmx.de>
Are A14 and A15 necessary with this little amount of memory?


Am 6. August 2016 18:37:41 schrieb Segher Boessenkool 
<segher@kernel.crashing.org>:

> On Sat, Aug 06, 2016 at 06:13:40PM +0200, Michał Pleban wrote:
>> > Right, that makes sense...  Except SID is treated "properly"!
>>
>> Yes, that's true. But maybe it's because they wanted to make SID write-only?
>
> No, the paddle regs need reading, and the counters do (wave form,
> envelope of chan 3).  The MAX has the paddles wired up (with a 4066
> no less) so it is meant to be used :-)
>
>> It's hard to explain it. When I hook up the GAL instead of 6703, we can
>> try to see if "fixing" the equations makes any difference - maybe
>> there's some reason to them, or maybe not.
>>
>> >> Maybe that's not very relevant, since the VIC memory map seems to
>> >> repeat itself every 16 kB.
>> > But not the 6703 equations!
>>
>> They do with regard to RAM and ROM. The IO chips are an anomaly, but
>> they don't overlap with RAM and ROM in the VIC memory map. So maybe
>> nobody bothered to fix the equations for them.
>
> Yeah.
>
>> It would be interesting to write some software which tries different
>> settings of VIC registers to see if it really "sees" these chips. Plus I
>> still don't know what drives the A15..A14 lines on VIC access - are they
>> just left floating?
>
> Probably.  There are two schematics of the MAX in circulation, both
> different, and both wrong it seems.  Or they are for different generations
> hardware.  But neither has this dealt with afaics.
>
> If nothing drives an address line it will hold its value for a value,
> and eventually drop to 0.  There is nothing that would pull the line
> one way or the other as far as I can see.
>
>
> Segher
>
>        Message was sent through the cbm-hackers mailing list



       Message was sent through the cbm-hackers mailing list
Received on 2016-08-06 18:00:02

Archive generated by hypermail 2.2.0.