There are two 6522s on each Lisa I/O board and each Dual Parallel Expansion Card.
On the 1/5 I/O Board, they are clocked from the 68000 E clock, which is the CPU clock divided by 10. So when using a 20.37504 MHz oscillator/crystal, the E clock/VIA clock is 0.509376 MHz.
On the 2/10 I/O Board and the Dual Parallel Expansion Card, they are clocked at the CPU clock divided by 4, so when using a 20.37504 MHz oscillator/crystal, the VIA clock is 1.273440 MHz.
Quote from: sigma7 on September 26, 2023, 04:50:42 PM
On the 2/10 I/O Board and the Dual Parallel Expansion Card, they are clocked at the CPU clock divided by 4, so when using a 20.37504 MHz oscillator/crystal, the VIA clock is 1.273440 MHz.
Does this have any noticeable impact on performance or OS compatibility?
Does the Parallel card in the 1/5 behave similarly to the 2/10?
I think it can mean that some ProFile emulators will work on the slower clock but not the faster one.
Quote from: jamesdenton on September 28, 2023, 02:34:29 PM
Quote from: sigma7 on September 26, 2023, 04:50:42 PM
On the 2/10 I/O Board and the Dual Parallel Expansion Card ... the VIA clock is 1.273440 MHz.
Does this have any noticeable impact on performance or OS compatibility?
Does the Parallel card in the 1/5 behave similarly to the 2/10?
Yes, the VIAs on the Dual Parallel card have the same clock frequency regardless of being in a 2/10 or 1/5. It is only the 1/5 I/O Board that is different.
The VIA clock frequency affects the two built-in timers of the VIA (and some other subtle characteristics).
There are a few effects of this:
- In the CPU ROM listing, there are branches by references to "fast timers" which is referring to having the faster VIA clock on the 2/10 I/O board.
- "Fast timers" is the primary meaning of the extra bit set in the "A8" vs "88" I/O ROM version.
- As a VIA timer on the I/O Board is used to control the frequency of the PWM output that drives the speaker, to obtain the same sound, different values need to be stored in the VIA timer for the 1/5 I/O Board.
- As a VIA timer on the I/O Board is used for some timing loops, different values need to be stored in the timer for the 1/5 I/O Board for LocalTalk communications and eg. the Macintosh Toolbox Time Manager. Mac timing software that isn't aware of the difference could give different results on a 1/5 and 2/10; this could effect something like a benchmarking software, but I don't recall if I've actually seen this artifact. Sub second timing can also be done using the ~60 Hz VBL interrupt, which isn't related to the VIAs.
- The response time of the VIA depends on the clock rate, so IIRC, the overall transfer rate of a parallel port hard disk is affected slightly. ie. a bit faster when using a Dual Parallel Card or a 2/10 I/O Board vs a bit slower with a 1/5 I/O Board. The VIA access method is also different (the 1/5 I/O Board uses a VPA bus cycle based on the CPU's E clock, while the others use a DTACK bus cycle based on the CPU clock), so the transfer rate would be affected by this difference as well as the VIA clock.
- The parallel ports can be configured to automatically pulse/strobe a signal when data is written or read. The length of the pulse is affected by the VIA clock frequency. I doubt this has any perceivable effect on the parallel port hard disk transfer rate, but it may be measurable with test equipment.
Quote from: stepleton on September 28, 2023, 04:50:20 PM
I think it can mean that some ProFile emulators will work on the slower clock but not the faster one.
I'm not aware of any ProFile emulators that have that issue... is there one?
IIRC, the Apple /// ProFile interface has the highest performance, so an emulator that works with the Apple /// is probably fine with any Lisa parallel port.
Quote from: sigma7 on September 28, 2023, 04:56:19 PM
I'm not aware of any ProFile emulators that have that issue... is there one?
The ArduinoFile emulator warns you about this problem (https://github.com/alexthecat123/ArduinoFile#very-important-warning), for now. Alex may be able to say more... the documentation suggests that it might be fixable in code.
QuoteThe ArduinoFile emulator warns you about this problem, for now. Alex may be able to say more... the documentation suggests that it might be fixable in code.
Yeah, I was barely able to get the ArduinoFile going on my 2/5 because the strobe pulses from the Lisa are bordering on being too fast for the Arduino to keep up with. Even slight changes to the code would cause it to miss one or two strobe pulses during each command, which obviously invalidates the data being transferred. I've tried getting it going on a 2/10, but the strobe pulses put out by the faster VIAs are just too fast/short for the Arduino and I haven't been able to figure out any ways to get it working. I'm sure that someone could probably optimize things enough to make it work, but I'm certainly not that person!
I'm working on a much improved version of the ArduinoFile right now that uses an ESP32 instead of an Arduino Mega and I'm really hoping that the higher speed of the ESP32 will make things work with the 2/10. I've already done a lot of improvements to the ESP32 version's tester mode (tons of new features and commands, including a full suite of Widget diagnostic commands), but I haven't tried the emulator mode yet. Who knows, it might just work without any modifications to the code, but I'm guessing that there will be at least a few things that need to be changed. It could be a little while before this is ready because I've been super busy with school this semester, but hopefully it won't take too long!
This was the reason why I chose DMA for the IDEfile. Even the 33 MHz Dallas DS87C320 with 1 cycle per CPU clock phase were too slow to reliably catch the strobe pulse of an Apple III. Now it works with a regular divide-by-12 i8031.
QuoteThis was the reason why I chose DMA for the IDEfile.
Yeah, I greatly considered going with DMA, but one of my main goals with the ArduinoFile was to make the hardware as simple as possible. Hopefully the ESP32 will be fast enough to handle things without having to resort to DMA hardware. I doubt even the ESP32 would be able to handle the speeds required by an Apple ///, but making it work with the 2/10 and parallel card VIAs seems doable!
Quote from: AlexTheCat123 on September 29, 2023, 09:53:32 AM
the strobe pulses from the Lisa are bordering on being too fast for the Arduino to keep up with. Even slight changes to the code would cause it to miss one or two strobe pulses during each command, which obviously invalidates the data being transferred. I've tried getting it going on a 2/10, but the strobe pulses put out by the faster VIAs are just too fast/short for the Arduino and I haven't been able to figure out any ways to get it working.
If the pulses are too short, then you could latch an edge or stretch them (eg. with a one-shot timer such as 74LS123).
To latch an edge without adding parts, one approach could be to set the pin as an interrupt that is masked and isn't actually serviced (since overhead of an interrupt is significant), and then poll the interrupt status flag to see if it has occurred. If so, clear the interrupt flag and read/write the byte.
If the data rate is too fast, I suppose you'll need to optimize or use a faster processor or switch to a DMA design such as used by Apple's ProFile and Patrick's IDEfile.
The data rate will depend on the operating environment. The DMA design of the ProFile can easily handle the 1 MB/s transfer rate of the Apple ///. The fastest data rates you'll encounter with a Lisa is when using MW+II with an XLerator on a 2/10, but IIRC, this is still slower than 1MB/s. Without an XLerator, I suspect BLU has the fastest transfer rate as uses MOVEP.L to read/write 4 bytes per 68K instruction.
The ProFile drivers in Lisa software vary substantially in data rate. It appears that initial specifications of ProFiles distributed to software developers were either very conservative, missing information, or somehow misunderstood, and the software written was not updated to reflect the capability of the production ProFiles. Some drivers (Xenix I think) adds an intentional delay between bytes in a transfer, others have unoptimized loops that move one byte at a time.
QuoteTo latch an edge without adding parts, one approach could be to set the pin as an interrupt that is masked and isn't actually serviced (since overhead of an interrupt is significant), and then poll the interrupt status flag to see if it has occurred. If so, clear the interrupt flag and read/write the byte.
Wow, that's an absolutely genius idea! I'll definitely give that a shot! I never considered using an interrupt without an ISR, but I bet that could solve all of my problems here.
QuoteThe fastest data rates you'll encounter with a Lisa is when using MW+II with an XLerator on a 2/10, but IIRC, this is still slower than 1MB/s.
I didn't even consider XLerator compatibility when designing the ArduinoFile, but that's definitely something else that I'm going to need to test!