james_w
Well-known member
Last edited by a moderator:
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Dynamac EL manual?
- Thread starter james_w
- Start date
apm
Well-known member
Having seen this strange beast in person, I was curious how the 640x400 video board works. Disassembling the "640 x 400" INIT from haplain's archive revealed a few tidbits:
Hardware
The DynaMac is based on a Plus logic board with stock ROMs. It appears that the VRAM for the DynaMac 640x400 display lives at $780000 in memory. That makes sense because it's an unused address space on the Plus.
There appears to be a control port at $7A0001, i.e. the low byte of address $7A0000. The Plus has a 16-bit bus but a lot of the peripherals use only 8 bits. Some of them are connected to the low byte of the bus while others are connected to the high byte. I don't know why that is, but anyway, it's the low byte (A0=1) here. Reading and writing bits to this address must query or set the status of the display somehow.
INIT
Most of the INIT seems concerned with a bunch of stuff relating to the cursor, which I didn't bother to pick through so I don't know exactly why it's there or what it does. But the interesting part starts at address offset $37C in the INIT resource. The approximate plan seems to be:
1. Check if the system ROM is what it expects. If not, exit.
2. Twiddle a series of bits on the control port at $7A0001 (this is the code starting at $398)
-- Set and test bit 3. If it reads low, exit.
-- Clear and test bit 1. If it reads low, exit.
-- Set bit 0, then read bit 2. If it reads high, exit.
3. Draw a grey checkerboard pattern in video memory at $780000. (this is the code starting at $3F6)
4. Copy the video data from the old screen address (i.e. in Plus system RAM) to somewhere within $780000 -- I think with a row / column offset, but I'm not sure.
5. Update the QuickDraw variables to point ScrnBase (i.e. the screen memory address) to $780000 and update the size to 640x400.
6. Call some system trap stuff that I haven't worked out, but probably gets QuickDraw to sort itself out again.
I'm guessing that some part in Step 2 (twiddling control bits) must flip a switch to tell the DynaMac video hardware to display from its native VRAM rather than from the Plus video. Then it's just a matter of pointing QuickDraw to the new VRAM buffer and away you go.
Hardware
The DynaMac is based on a Plus logic board with stock ROMs. It appears that the VRAM for the DynaMac 640x400 display lives at $780000 in memory. That makes sense because it's an unused address space on the Plus.
There appears to be a control port at $7A0001, i.e. the low byte of address $7A0000. The Plus has a 16-bit bus but a lot of the peripherals use only 8 bits. Some of them are connected to the low byte of the bus while others are connected to the high byte. I don't know why that is, but anyway, it's the low byte (A0=1) here. Reading and writing bits to this address must query or set the status of the display somehow.
INIT
Most of the INIT seems concerned with a bunch of stuff relating to the cursor, which I didn't bother to pick through so I don't know exactly why it's there or what it does. But the interesting part starts at address offset $37C in the INIT resource. The approximate plan seems to be:
1. Check if the system ROM is what it expects. If not, exit.
2. Twiddle a series of bits on the control port at $7A0001 (this is the code starting at $398)
-- Set and test bit 3. If it reads low, exit.
-- Clear and test bit 1. If it reads low, exit.
-- Set bit 0, then read bit 2. If it reads high, exit.
3. Draw a grey checkerboard pattern in video memory at $780000. (this is the code starting at $3F6)
4. Copy the video data from the old screen address (i.e. in Plus system RAM) to somewhere within $780000 -- I think with a row / column offset, but I'm not sure.
5. Update the QuickDraw variables to point ScrnBase (i.e. the screen memory address) to $780000 and update the size to 640x400.
6. Call some system trap stuff that I haven't worked out, but probably gets QuickDraw to sort itself out again.
I'm guessing that some part in Step 2 (twiddling control bits) must flip a switch to tell the DynaMac video hardware to display from its native VRAM rather than from the Plus video. Then it's just a matter of pointing QuickDraw to the new VRAM buffer and away you go.
ConventionalMemories
Member
This link seems to be down. anyone have a backup they could share? tnx
Compgeke
Well-known member
Once I get home next week I can bring it back up. That web host is with the lord now, but I've got a full site backup still. I'll merge it into the newer-and-greater project
.ConventionalMemories
Member
Great, thanks.Once I get home next week I can bring it back up. That web host is with the lord now, but I've got a full site backup still. I'll merge it into the newer-and-greater project
If you could share a copy of that dynamac folder. That would be great. Cheers.
ConventionalMemories
Member
Have you've had a chance to look for the files by any chance? I would love to get my Dynamac up and runningOnce I get home next week I can bring it back up. That web host is with the lord now, but I've got a full site backup still. I'll merge it into the newer-and-greater project
Compgeke
Well-known member
Finally back home! Had myself gone 3 of the last 4 weeksHave you've had a chance to look for the files by any chance? I would love to get my Dynamac up and running
. Here's a link:index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
ConventionalMemories
Member
Thank you, that will help a lot,Finally back home! Had myself gone 3 of the last 4 weeks
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)
index - powered by h5ai v0.29.2 (https://larsjung.de/h5ai/)fsck.technology
