Search results

Regarding my comment from a couple of years ago, as a Windows user, I have found the repos to be very problematic. IMO, all the files on the repos should be in .hqx format (and maybe zipped) and/or auto-converted on upload (if .sit) so that the files work when they have to transition through a...

Did the replacement part fix the problem? The beads on the tantalums were just for automated assembly spacing, manufacturability and consistency. The casing extends down the leads and would interfere with wave soldering, etc. And, there can be problems if the parts tip over at angle and the...

It was pretty cool in 1988. Alas, it didn't survive. :'( But...I may be able to put together a demo if everything still works.

The Spectrum/8 was 8-bit only. I will look over the earlier posts and see if I have anything to add. As I recall, I *think* OSC2 should work and the firmware runs a TimeDBRA timing loop at startup to try to find compatible oscillators that match supported (or user-defined) configs. But maybe...

Paul is definitely the guy to answer Squid questions!! :D

Great! Glad those files are good - thanks for confirming! Nice to see that you could upgrade your card! Regarding SuperVideo, I think that the ColorCard/24 v1.3 firmware update included the SuperMac VDI ("Video Driver Interface") spec - a patchable, generalized driver that could, for example...

After some digging, I found my board - and luckily, it is v1.3! For some reason, I thought it was v1.2. Attached are the files from dump of my production ColorCard/24 v1.3 ROM -- including: - binary file - inverted binary file - motorola srec file The ROM size for ColorCard/24 is: 27C256 On...

Edit above: "especially coming 24-bit" -- should be "especially concerning 24-bit" ... and the point about the gamma support was that it was not implemented correctly in v1.0. And it looks like v1.3 did ship in 1990. So say the wildly overpriced eBay gods. I sent one for David Cook to try out...

I have been away for a while, but just logged back in and noticed this thread. I know there was a v1.2 or v1.3 ROM for the ColorCard/24 from around the 1990 timeframe. I have it on a board somewhere. It is definitely worth upgrading and fixed a number of issues: -- config on the IIci and...

@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...

That should say bit numbers above -- the data will be a 1 or 0 at those locations.

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...