Alright, sweet. Success under WinXP with WinUAE.
http://img534.imageshack.us/img534/6053/worksl.png
For the record, nwgatwcfan's suggestion to check "synchronize clock" under Miscellaneous did not work. It
did set the time in the Amiga environment (as verified by typing "date" at the
2> prompt during boot-up), but ESQ itself still thought it was January 1, 1970 at 12:00 AM. Only tin's and hen7713's MSM624B suggestion worked (checking MSM624B under Adv. Chipset > Battery Backed-Up Real Time Clock). (tin's and hen7713's way also resulted in the correct date being reported when typing "date" at the
2> prompt, FYI.)
Anyway, this all appears to jive with LocalH's experiences with ESQ and with his real Amiga. AmigaDOS maintains a virtual clock in memory that's separate from the host Amiga's battery-powered clock. When AmigaDOS boots, it sets its virtual clock according to the battery-powered clock. But any changes made to the virtual clock with the "date" command thereafter don't change the battery-powered clock itself. And since ESQ only looks at the battery-powered clock [or the satellite feed] for clock information, he had to track down the right AmigaDOS tool to alter the battery-powered clock, rather than just using the conventional clock setting command.
So I guess what's happening in WinUAE is similar. If you check MSM624B, the emulated battery-powered clock is set to your Windows PC's current time. Then as AmigaDOS boots, it reads that emulated battery clock and sets its separate virtual clock to match. Yielding correct time for both AmigaDOS and ESQ. But if instead of checking MSM624B you check "synchronize clock" instead, no emulated battery clock is created; and WinUAE just waits for AmigaDOS to load and then haxishly directly modifies the memory space of AmigaDOS' separate virtual clock. Resulting in a correct AmigaDOS virtual clock (as evidenced by typing date) but no battery-powered clock information for ESQ to read (ESQ thinks its 1/1/1970). So bottom line for WinUAE users: the correct method is checking MSM624B (or even checking both MSM624B and "synchronize clock"), but never checking only "synchronize clock" alone.
Anywho. I'm using WinXP Pro (32 bit version) and went with the serial port emulation software nwgatwcfan suggested in another thread for this. Specifically AGC's
COM Port Data Emulator & Traffic Generator for data injection/sniffing and Eterlogic's
Virtual Serial Ports Emulator to create a virtual null modem-style link between the injector and WinUAE. In VSPE, like this:
1,
2,
3. Then in CPDE&TG, like this:
1,
2. Then in WinUAE, used
these IO settings when starting ESQ. And finally once ESQ was up and running and scrolling with its "no listings" message, I made a file called test.bin containing the suggested test bytes from post 1 of this thread, and clicked "[Start]" in CPDE&TG to inject them ... the overall result being: test.bin -> CPDE&TG -> COM4 -> VSPE -> COM2 -> WinUAE -> ESQ.
Incidentally, tin:
No, no, hang on, it's starting to make some sense! I would lay good money that the demod and audio cards talk to each other over the ISA bus. No reason why they can't. Amiga signals demod card via serial, it signals audio card over the bus. Makes sense to me, especially as all other options (including the brown and grey wires, sorry) make no sense to me
That would require that the Amiga's ISA slots be active for data, though, wouldn't it? As far as I know, the ISA slots in Amigas only provide voltage for powering cards, but not data connectivity.
I suppose theoretically there could be an active ISA bus that allowed cards to talk to each other, even if the ISA bus wasn't connected to the rest of the motherboard (i.e. where ISA cards could intercommunicate but not talk to any of the software running on the Amiga). Guess only an Amgia platform expert could say if this is true, though I'd doubt it. The fact those brown/grey wires exist at all suggests to me that, at least via ISA, those cards were as much isolated from ESQ as from each other. Hmm...
And to Ari: did my e-mail of the 18th reach you? I don't need a [fast] reply, just that my ISP's outgoing mail delivery has had some problems this week and I wanna be sure you got it.
