[Coco] Coco 3 Memory Map Questions

[Dave Philipsen]

Well, I suppose you could do that if you really have the ambition. It 
would be a lot of work to find out something that may not be all that 
important...

And I'm not trying to flame Darren because I understand and agree 
completely with him.  But sometimes when you look at a problem from a 
different angle you can find a way to get it done that might not be so 
apparent on the surface.  Maybe one of the reasons my thinking is out in 
left field like this is that I was toying around with the idea of 
creating an interrupt controller in FPGA that would sort of do the same 
thing.  Depending on where the interrupt came from the controller would 
automatically present a different vector at the IRQ vector address.  So 
if you had a number of different devices interrupting the CPU on the 
same interrupt line then you wouldn't have to write code to determine 
where the interrupt came from so it could be serviced.  Your program or 
system would just give the address of the interrupt service routine to 
the controller and let the hardware handle it.

Dave


On 2/11/2016 5:03 PM, Camillus wrote:
> Dave,
>
> Would it then not better to connect a logic analyzer to the :
>
> addressbus = 16
> databus      = 8
> the GIME control lines for ROM selection  = 3   ( not sure have to read the schematics)
> ROM CS, SE = 2 ( SE = controlled, 1 if is fixed to vcc/gnd)
>
> and clock the *halt line to step to the full range of 65K to have a idea hat really happens.
> Of course this would only work if all of the levels on all those lines are available when 6809 is halted.
> If they go to Z state then all is lost or at least invalid I thought.
>
> Hooking up an arduino with enough I/O lines ( 25 ), could do this job and put it out to serial port from where the data can be saved to a file. I believe a Mega2560 has that # of I/O which I happen to have.
> I read once that a person did kind of the same thing with a 6502 cpu on hackaday, to find the right timing for his project or something he needed to know for sure.
>
> Cool explanation though, never would have thought on that one, wonder how it then works on all those emulators for coco3?
>
>
> cb
>   
>
>
> Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird]
> On 2/11/2016 4:00:49 PM, Dave Philipsen <dave at davebiz.com> wrote:
>
>
> On 2/11/2016 12:13 PM, Darren A wrote:
>> On Thu, Feb 11, 2016 at 10:51 AM, Dave Philipsen wrote:
>>
>>> I would have to agree with Darren. However, since the chip select of the
>>> ROM is controlled by the GIME it is possible (although not likely) that the
>>> GIME could cause something other than the ROM contents at 7FFx to show up
>>> when the CPU addresses FFFx.
>>
>> The GIME, through control of the ROM's chip select, obviously determines
>> which addresses the ROM will respond to. It cannot however alter the
>> address being presented to the ROM on A0-A14. To map a CPU access of $FFFx
>> to the $BFFx locations ($3FFx inside the ROM) the A14 address line would
>> need to be inverted. There is nothing on the address bus between the CPU
>> and the ROM to do this.
> And it's not necessary to explain in more detail since I do agree with you.
>> It is possible for the GIME to map the vectors to $7FFx, but that is not
>> what we are talking about.
> I understand that's not specifically what was being discussed but I
> decided to throw that out there as a possibility although very remote.
> Another possibility (also very very remote but still within the realm of
> possibility) is this:
>
> The GIME chip has access to the address lines, the data lines, and the
> reset line. We assume that the address lines and the reset are merely
> inputs to the GIME. But the GIME could sense when the 6809 goes into
> reset on the falling edge of the signal and then hold the CPU in reset
> for a longer period of time. This is how some CPU monitor chips like
> the DS1232 work. It's true that the schematic seems to indicate that
> the reset signal is an input to the GIME but let's assume that the GIME
> can also drive that pin low if it wants to. The GIME has the master
> clock signal so it can count down a specific delay if it wants to. Now
> during the time that the CPU is being held in reset suppose that the
> GIME chip puts addresses out on the address lines and reads data on the
> data lines from the ROM (yes, I know it's a long stretch and very very
> unlikely). So the GIME could feasibly read the reset vectors out of any
> particular area of the ROM it wanted to (maybe $3FFx???) and then it
> could store the data in some internal (volatile) registers. Now when
> the CPU finally comes out of reset some microseconds later because the
> GIME has released its evil grip....the CPU proceeds to set up the
> address lines to read the reset vector at $FFFx. The GIME sees this
> address on the address lines and instead of exerting the chip select for
> the ROM it now fetches the data from its internal registers and puts
> that out on the data lines.
>
> Now I am not even remotely suggesting that this is what happens. I'm
> just pointing out that it is not 100% impossible for the reset vectors
> to be stored at $3FFx in the ROM. It *is* in the realm of possibility.
> If I had an FPGA wired up to a 6809 just like the GIME is wired to the
> 6809 I can almost guarantee you it could be done (as long as the FPGA
> had 5v I/O).
>
> Dave (thinking outside of the box mode)
>
>> - Darren
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>