@eharmon - Interesting - perfect tool for this problem! @Arbee
...hmmm...or not:
"The ROM image files that SlotRom saves are copyright Apple Computer, and may not be redistributed."
So...maybe just skip it and see if there is anything around the address I mention above, then try to read 64K.
I dumped memory on my Thunder/24 and it looks like the ROM is mapped to $e100000 at the top of the memory space above squid. So, if someone has a Thunder II 1600 GX (@olePigeon ?), you could try reading 64K from $Se1000000 with Macsbug and see what you get to see if the mapping is the same...
It sounds great, but I don't think it will be that simple. :D
The potential problems could be:
1. There is more than 1 table to worry about. There is the monitor table (the one you're talking about), but also the resolution/depth table. And, if you are modifying the 1360 ROM, it probably...
Great! 70Hz should look better! That is the highest refresh rate without using the externa auxl pad and a 135MHz oscillator. It may be possible to socket it on the back side and mirror the pins on a mini pcb so that you could use config $01...but gravy. Might be more useful for testing...
Great job! That's awesome! Are you going to try 1280x1024 @ 130MHz now? :D
1600x1200 might be possible -- the DAC supports it per the Brooktree doc...and there are 165Mhz parts. Another research project.
I went back to look at my earlier post on the 24/32-bit sRsrc tables. It was Post #50...
Check 1-bit 1280x1024 at the base+offset location. Otherwise, boot in different depths and see if that helps pinpoint the problem (in the event that it's happening after SetDepth).
Your vertical looks correct. I may have erred in an earlier comment on timing - forgetting that the blanking area...
It sounds like a sync issue. Try increasing VES by increments of +1.
There is a 960 value that hasn't been changed somewhere. The vertical delta to 1024 is ~1", or 64 pixels.
I'll look at the disassembly again. The spot where I commented in a previous post about checkerboard alternating lines...
Good -- otherwise...??? If you were writing a 1 only (bit 0) to the strobe location (is at the base address, or offset $0), that would be interesting vs. having to write 0L or -1L for the other FSx bits. That might indicate that bit 0 is mapped to register 0/strobe at the base and each register...
Yeah - I might have been a little bit excited there on the code timing. I transposed the post-delay to fit what I was thinking. Looking at it again, I'm not sure those delays do very much, unless it's for some other hardware settling. The 68K instruction timing is slow enough so that the delays...
@eharmon Below is another snippet of the disassembly from @jmacz 's PrimaryInit post that has the RAM fill. It looks like it either uses a horizontal value of 512 or 256 (which would be rowbytes -- added from d4 to a1). In 1-bit mode, that is either 2048 or 4096 1-bit pixels. The vertical value...
Below is a quick comparison of the Thunder II boards and some additional thoughts.
Thunder II GX 1360 pic below with 3x Bt458LPJ135, socketed DIP ROM and a 14.31818MHz clkRef for ICS1494. The DAC is an 85-pin plastic J-Lead package and marked as -135 -- likely indicates the top speed (135MHz)...
@eharmon You're very welcome! It has been a looong time since I used to do this stuff - yeesh - ...but it's definitely helping me remember -- especially hearing the name Ardent and seeing the clock docs. I wondered how you came up with the part number, but then I realized from the pictures that...
@eharmon - good! That may be the best you can do. It sounds like you are having clock alignment/rounding issues with the missing pixels.
Here are my morning thoughts: I looked back in the thread and your monitor is the E178FP. From the Dell User Guide, the supported modes are as follows...
Sorry - I edited my post above to add some additional info. Your HSB-HEB should be 160 @ x8 (active area) and HES may be too high, but it depends on the expected monitor timing.
Great job! And I definitely now remember Ardent and masking upon seeing this discussion. The 130.48Mhz frequency for $0f probably translates to 1280x1024 at 7xHz (and possibly a 16x multiplier). And, the different mask versions probably just indicate an extension of the same setup. The base...
@eharmon -- Great -- so that pins down the clock devices, as follows:
Thunder/24 flavor boards (including PDQ+) are CLK-02
Thunder II boards are CLK-03
Thunder IV are ICD2062B
@Arbee -- Thanks for looking that up on the Thunder IV. Yeah - good point about CLK-02. Could be.
14.31818MHz is also the frequency used by NTSC, but is called out in the ICD2062B spec.
@eharmon - sure - happy to help! :)
I was thinking about this problem last night, and coming at things from a different engineering direction, focusing on the CLK-02 (or CLK-0?) IC might be helpful. We know certain things about it. It is the clock synthesizer (in the lower right-hand corner on...
A couple of other details: The counter registers should be read-only. So, writes to those registers should be ignored, but I have never tried to write to them. :D And, now that I think of it, the VINT function should be the same as TMS34061. The point of VINT was to set a value that would...