>Message: 17
>Date: Mon, 15 Jan 2024 12:52:15 -0500
>From: Bill Gunshannon <bill.gunshannon(a)hotmail.com>
>Subject: [cctalk] Re: WWVB
>To: cctalk(a)classiccmp.org
>Message-ID: <SA1PR17MB5737C194F181927517114C55ED6C2(a)SA1PR17MB5737.nam
prd17.prod.outlook.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>On 1/15/2024 10:47 AM, Chris Elmquist via cctalk wrote:
>> On Sunday (01/14/2024 at 09:55PM -0600), Chris Elmquist via cctalk wrote:
>>> There are a number of WWVB simulator projects out there that will transmit a weak but usable signal to your clock after getting sync’d from ntp or GPS NMEA time messages. They were developed to help people develop receivers :-) One in particular uses an AVR and it should be pretty simple to make it do the “old protocol”. You’d then hide this behind your clock and it will sync to it instead of the actual WWVB signal. Solves the protocol problem and the weak signal problem from real WWVB with one little circuit.
>>>
>>> If Google does not provide, I can dig up some links tomorrow.
>>
>> Hmm. Strange. I did follow-up shortly after the above post with this
>> link,
>>
>> https://www.instructables.com/WWVB-Simulator/
>>
>> but I don't see that that made it to the list.
>>
>> Chris
>>
>
>It did. I got it.
>
>bill
Your original email with the link did not make it into the digest, which is what I receive.
Chirs, Did you also send it directly to Bill. Perhaps that is what he got.
Bob
This is kind computer related but maybe more ham radio related
but I figure if anywhere, here is the place to find an answer.
I have a SkyScan ATOMIC CLOCK.
It is supposed to get its time from WWVB.
The antenna icon that is supposed to mean it is receiving
WWVB is on.
Your probably wondering why I keep saying "supposed to".
The clock is always wrong. Slow by about 2 minutes.
Is there a known problem with WWVB?
bill
Hi folks -- long time no post.
I'm wondering if there's anyone who would be interested in trying to fix my
Shugart 850/851 8-inch floppy drive. It was new old stock when I bought it,
and hasn't been used much, but last time I tried it, it would no longer
read any data from the back of a floppy, only from the front. I use it with
a Catweasel and my cw2dmk software, so I was able to try a few experiments
from the software side. What I see is just plain noise coming out on the
data line when reading the back.
It's possible of course that some unobtainium chip has gone bad, so I don't
expect much. But it would be nice if someone with more electronics skill
than me, and more knowledge about these drives in particular, would be
willing to take a look at it.
The drive is of course big and tough to ship, so it probably only makes
sense for someone within driving distance (I can drive it over or you can
come by), which means being in the SF Bay area. I live in Palo Alto right
near downtown.
FWIW, the drive and a power supply are mounted in a case that I made by
ripping the guts out of a surplus desktop PC case. The power supply seems
fine and the drive can read the front of disks fine.
Thanks for any help,
Tim
Hi!
Due to a broken water line, I ended up with a blown BM200-3601 power
supply in a HP workstation. These seem to be notoriously failing due
to bad caps, but mine was fine until flooded.
Found few offers in the USA (~ 1400 US-$), but adding taxes and
shipping to Germany, that would probably end at around 2000 €. That's
well beyond what I'd be willing to spend on it. :(
Thanks,
Jan-Benedict
--
For those needing a decent price on hotels, check out the hotel blocks
page: https://vcfed.org/vcf-east-hotel-blocks/
Thanks!
Jeff Brace
VCF National Board Member Chairman & Vice President
Vintage Computer Festival East Showrunner
VCF Mid-Atlantic Event Manager
Vintage Computer Federation is a 501c3 charity
https://vcfed.org/ <http://www.vcfed.org/>
jeffrey(a)vcfed.org
Hi all
Oops that went off before I was finished with it.
>I suspect that I can figure out from the pattern of I/O accesses
>which devices are at which address in the memory map, at least if I
>bring up an emulation in MAME. That should at least allow writing
>new code for it, and _maybe_ even figuring out which CRT controller
>the video hardware uses and where in the memory map it is. (I
>suspect the 6845 and/or 6847 just from the time period, but who
>knows? Gotta see what it actually do when trying to show the âIPL
>IN PROGRESSâ string contained in the ROM, or one of the couple
>error strings )
As far as I can tell this is where a character gets displayed.
; character in +1(A6)
00FFCE0C : 48E7 C000 MOVEM.L D0,D1,-(A7)
00FFCE10 : 302B 06AC MOVE.W +1708(A3),D0 ; get something
00FFCE14 : 6122 BSR $00FFCE38 ; do something
00FFCE16 : 0040 8000 ORI.W #$8000,D0
00FFCE1A : 11C0 8001 MOVE.B D0,$00FF8001 ; Low byte
00FFCE1E : E048 LSR.W #8,D0
00FFCE20 : 11C0 8003 MOVE.B D0,$00FF8003 ; High byte
00FFCE24 : 11EE 0001 8005 MOVE.B +1(A6),$00FF8005 ; Character
00FFCE2A : 0838 0006 801B BTST #6,$00FF801B ; Wait
for a flag
00FFCE30 : 66F8 BNE $00FFCE2A
00FFCE32 : 4CDF 0003 MOVEM.L (A7)+,D0,D1
00FFCE36 : 4E75 RTS
; Here with something (from $06AC(A3)) in D0
; current guess, it's the cursor position, which then gets translated
; to an X and a Y byte in D0.w
00FFCE38 : 0C2B 0050 06B7 CMPI.B #$50,+1719(A3)
00FFCE3E : 6628 BNE $00FFCE68 ; Return
00FFCE40 : 48C0 EXT.L D0
00FFCE42 : 81FC 0050 DIVS #$0050,D0
00FFCE46 : 4840 SWAP D0
00FFCE48 : 3200 MOVE.W D0,D1
00FFCE4A : 4840 SWAP D0
00FFCE4C : ED48 LSL.W #6,D0
00FFCE4E : 0C01 0040 CMPI.B #$40,D1
00FFCE52 : 6C08 BGE $00FFCE5C
00FFCE54 : 11FC 0000 8013 MOVE.B #$00,$00FF8013
00FFCE5A : 600A BRA $00FFCE66
00FFCE5C : 0441 0040 SUBI.W #$0040,D1
00FFCE60 : 11FC 0001 8013 MOVE.B #$01,$00FF8013
00FFCE66 : 8041 OR.W D1,D0
00FFCE68 : 4E75 RTS
Or maybe it's talking to a chip (not 6845 which is memory mapped or
7220 which has two registers only) and someone recognises it?
W
Hi all
Chris gave me a copy of the boot ROM and I played around with it a bit.
>I threw the 4KB of boot ROM in Ghidra and confirmed a couple things:
>
>- At boot, ROM is mapped to 0, and then remapped either by a write
>to the location or by a cycle counter: The initial stack pointer at
>0x0 is 0x0001fffe and the initial program counter at 0x4 is
>0x00ffc026, indicating the ROM is normally located at 0x00ffc000.
>- The ROM freely interchanges addresses in the
>0x00ffc000..0x00ffffff range and addresses in the
>0xffffc000..0xffffffff range, which is annoying to deal with in Ghidra.
The code takes advantage of the 68000 sign-extend on absolute short
addressing mode, like move.b #$00, $8011. IDA correctly disassembles
this to "move.b #0,($FF8011).w". I assume Ghidra if sign-extending
it all the way to FFFF8011?
>- I/O devices appear to be in the 0x00ff8000..0x00ffbfff range, all
>of the devices accessed via the bootstrap seem to be barely above 0x00ff8000.
>- Only NMI, bus error, interrupt 2, and interrupt 5 are set up by
>the bootstrap.
Yup.
>- The bootstrap is very bare-bones but still has a bunch of
>indirection in it; itâs obviously written in assembly, but it does
>seem to have parameterization so it may support both console and serial I/O.
I suspect either some low-level high-level language, or massive use
of macros (which is in effect a low-level high-level language :-) Code like:
; Called with A6 pointing to a length and a string address
00FFCA4C : 48E7 8080 MOVEM.L D0,A0,-(A7)
00FFCA50 : 3016 MOVE.W (A6),D0 ; length
00FFCA52 : 48C0 EXT.L D0
00FFCA54 : 206E 0002 MOVEA.L +2(A6),A0 ;
pointer to string
00FFCA58 : 508E ADDQ.L #8,A6 ; clear stack
00FFCA5A : 5380 SUBQ.L #1,D0
00FFCA5C : 6B0E BMI $00FFCA6C ; done
00FFCA5E : 518E SUBQ.L #8,A6 ;
make space on stack again
00FFCA60 : 1D58 0001 MOVE.B (A0)+,+1(A6) ;
one character on stack
00FFCA64 : 4EB8 C566 JSR $00FFC566
00FFCA68 : 51C8 FFF4 DBF D0,$00FFCA5E ; loop
00FFCA6C : 4CDF 0101 MOVEM.L (A7)+,D0,A0
00FFCA70 : 4E75 RTS
>I suspect that I can figure out from the pattern of I/O accesses
>which devices are at which address in the memory map, at least if I
>bring up an emulation in MAME. That should at least allow writing
>new code for it, and _maybe_ even figuring out which CRT controller
>the video hardware uses and where in the memory map it is. (I
>suspect the 6845 and/or 6847 just from the time period, but who
>knows? Gotta see what it actually do when trying to show the âIPL
>IN PROGRESSâ string contained in the ROM, or one of the couple
>error strings )
> Chris
