| Re: Transwarp - How do they work? [message #354119 is a reply to message #354116] |
Tue, 10 October 2017 07:40   |
|
|
Originally posted by: R.Kiefer.SPAEM
Anthony Ortiz wrote:
> You should be able to hold DMA for as long as you want, otherwise how do
> accelerators such as the Transwarp work?
The Transwarp and other accelerator boards use their own processor. The
65[C]02 from the mainboard doesn't start and won't be used.
Regards, Ralf
|
|
|
|
| Re: Transwarp - How do they work? [message #354130 is a reply to message #354119] |
Tue, 10 October 2017 09:44 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
|
What I'm saying is that the only reason why the Transwarp is able to take over is by dropping the DMA line low; the 6502 is then disconnected from the system and you now have full control until you release the DMA line (and restart the system if DMA control duration lasted more than just a few cycles). That's what this thread answered a while back.
|
|
|
|
| Re: Transwarp - How do they work? [message #354144 is a reply to message #354112] |
Tue, 10 October 2017 13:29 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Anthony Ortiz <anthonypaulo@gmail.com> wrote:
> Oh, and for the initial state during startup, should I pull input low (of
> the SN7407N) using a 10k resistor? I checked data sheet and logic table
> doesn't say what output would be if input is floating (as would be the
> case during startup).
>
The reset circuitry of the Apple is based on a fixed RC delay, so you
should let the Apple reset itself before pulling on /DMA.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
|
|
|
|
| Re: Transwarp - How do they work? [message #354161 is a reply to message #354145] |
Tue, 10 October 2017 17:07 |
|
|
Originally posted by: MG
On Tuesday, October 10, 2017 at 10:49:41 AM UTC-7, Anthony Ortiz wrote:
> Hmmm... then how do I determine when it's time to pull DMA low?
You might watch the bus for the 6502's RESET sequence, the same way Sather describes the IIe MMU as doing on page 4-14 of _Understanding the Apple IIe_. Three sequenced page 1 addresses followed by read of $FFFC. That lets you know the CPU has reset and is ready to start executing code.
MG
|
|
|
|
|
|
| Re: Transwarp - How do they work? [message #355012 is a reply to message #354162] |
Fri, 20 October 2017 13:18 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
|
Anyone know if the Transwarp handled the mouse and keyboard IO any differently? That is, I'm sure you don't want a fast running program slow down to a 1mhz crawl every time your mouse pointer moves or as you scan for a potential keypress or both. If it doesn't handle it, I wonder if there's any way they could have avoided the hit.
|
|
|
|
| Re: Transwarp - How do they work? [message #355013 is a reply to message #355012] |
Fri, 20 October 2017 13:43 |
|
|
Originally posted by: R.Kiefer.SPAEM
Anthony Ortiz wrote:
> Anyone know if the Transwarp handled the mouse and keyboard IO any
> differently?
The code from UCSD BIOS can run without any change at 1MHz, 3.6MHz or
12.5MHz. When code is idling the keyboard is asked very often (lda
$C010). But this is just one slow cycle.
When modifying this BIOS I wanted to add a keyboad driver which is
triggered by a timer (6522). But you need an additional timer chip.
> That is, I'm sure you don't want a fast running program slow down to a
> 1mhz crawl every time your mouse pointer moves or as you scan for a
> potential keypress or both.
Changing the mouse pointer can theoretically slow down the fast CPU to
run the write cycles in video screen buffer on the main board. But just
the write cycles if they are too often. This never happens with a 3.6MHz
Transwarp.
Regards, Ralf
|
|
|
|
| Re: Transwarp - How do they work? [message #355021 is a reply to message #355013] |
Fri, 20 October 2017 15:41 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
Anthony Ortiz wrote:
> Anyone know if the Transwarp handled the mouse and keyboard IO any
> differently?
> The code from UCSD BIOS can run
Pardon my ignorance, what is UCSD? Link?
> When modifying this BIOS I wanted to add a keyboad driver which is
triggered by a timer (6522). But you need an additional timer chip.
I would imagine that even if you did do this it would still need to poll the keyboard strobe for key presses periodically and I presume send an interrupt?
> Changing the mouse pointer can theoretically slow down the fast CPU to
run the write cycles in video screen buffer on the main board. But just
the write cycles if they are too often. This never happens with a 3.6MHz Transwarp
This last paragraph lost me. I would think there is a definite guaranteed slow down since, even though the mouse may trigger an interrupt, that interrupt needs to be processed and eventually read the x and y coordinates from the mouse card which slows it down to 1mhz, no? I also didn't understand what you meant by the write cycles, nor why the Transwarp would not be affected by any of this. I'm no Sathers so I would appreciate an education. :)
In my mind I would have the Transwarp constantly poll the keyboard when it's not performing other IO and keep the last state ready for quick access; I don't know if it does that. I would also do the same for the mouse.
Regards,
Anthony
|
|
|
|
| Re: Transwarp - How do they work? [message #355028 is a reply to message #355021] |
Fri, 20 October 2017 16:40 |
|
|
Originally posted by: R.Kiefer.SPAEM
Anthony Ortiz wrote:
>> The code from UCSD BIOS can run
>
> Pardon my ignorance, what is UCSD? Link?
Sorry, UCSD-p-System, often called "Pascal".
>> When modifying this BIOS I wanted to add a keyboad driver which is
> triggered by a timer (6522). But you need an additional timer chip.
>
> I would imagine that even if you did do this it would still need to poll
> the keyboard strobe for key presses periodically and I presume send an
> interrupt?
Yes, this is independant from CPU frequency. An interrupt every 50msec
(20Hz) seems to be sufficient.
>> Changing the mouse pointer can theoretically slow down the fast CPU to
> run the write cycles in video screen buffer on the main board. But just
> the write cycles if they are too often. This never happens with a 3.6MHz
> Transwarp
>
> This last paragraph lost me. I would think there is a definite guaranteed
> slow down since, even though the mouse may trigger an interrupt, that
> interrupt needs to be processed and eventually read the x and y
> coordinates from the mouse card which slows it down to 1mhz, no?
Ok, there is a firmware ROM on the mouse card. This driver in ROM will
slow down the fast cpu to 1MHz exactly when this code is running. But
code in RAM runs at full speed, if you set the DIP switch to fast (OPEN
#7 in block 2, means the right DIP switch, if your mouse card is in slot
#7). And that's what I meant: the code which moves the mouse pointer on
the screen is typically located in the language card and is running at
fast speed.
> I also didn't understand what you meant by the write cycles, nor why the
> Transwarp would not be affected by any of this.
I assumed that it's clear that code from any ROM on a slot card is
always running at 1MHz. The code from the local RAM of the Transwarp is
always running fast except there was an access to a slot card which
forces slow execution for some msec like the disk controller code.
> In my mind I would have the Transwarp constantly poll the keyboard when
> it's not performing other IO and keep the last state ready for quick
> access; I don't know if it does that. I would also do the same for the
> mouse.
I expect that the driver which polls the keyboard is always part of the
operating system. This code is located in the language card, means it's
fast. If you move the mouse driver code from the slot to the RAM onto
the Transwarp this code will also be fast.
Regards, Ralf
|
|
|
|
| Re: Transwarp - How do they work? [message #355041 is a reply to message #355028] |
Fri, 20 October 2017 18:01 |
anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
|
Thanks for the explanation! What I still don't get are the write cycles... what's being written? We were talking speed, mice, keyboard, etc... and then you mentioned writes and I don't know what you mean
|
|
|
|
| Re: Transwarp - How do they work? [message #355042 is a reply to message #355041] |
Fri, 20 October 2017 18:57 |
|
|
Originally posted by: R.Kiefer.SPAEM
Anthony Ortiz wrote:
> What I still don't get are the write cycles... what's being written? We
> were talking speed, mice, keyboard, etc... and then you mentioned
> writes and I don't know what you mean
You find my description here:
Message-ID: <1nbbzln.lq7u64gicudyN%R.Kiefer.SPAEM@gmx.de>
Additional info: The screen buffer is part of the mainboard, means that
this RAM is accessed by the slow speed of the mainboard. I'm not sure if
the Transwarp works in the same way my 12.5MHz accelerator does: write
access to the mainboard is done simultanously and in background by
special buffers on the board. Read access of the screen buffers is done
without access to the slow mainboard RAM because this RAM is also
available on the accelerator board.
Summary: access to the screen buffers is typically as fast as local
access on the accelerator board.
Regards, Ralf
|
|
|
|
|
|
| Re: Transwarp - How do they work? [message #356411 is a reply to message #356410] |
Wed, 01 November 2017 15:00 |
|
|
Originally posted by: R.Kiefer.SPAEM
Anthony Ortiz wrote:
> Does anyone know if AE had a license to use the Apple II Roms for both II
> and IIgs Transwarps or did it do a one time copy of ROMs to RAM at
> initialization?
The code from the preboot ROM copies the Apple ROMs to the local and
fast RAM. So does the Transwarp 1 and the Schaetzle&Bsteh DC65.
Regards, Ralf
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
