Thursday, November 2, 2017

My Weatherdirect boxes don't work anymore

*sniff* Weatherdirect has shut down its forecast service for their wireless forecasters that connected to the internet.

My unit(s) stopped working a couple of weeks ago and I read this on weatherdirect.com:

August 9th, 2017

IMPORTANT ANNOUNCEMENT REGARDING WEATHER DIRECT FORECASTING SERVICE

If you are currently utilizing a WD- or WA- Series (Model # begins with WD- or WA-) weather station to receive forecasts, please read on for important information about your station.

Due to changing technology, reduced demand and a changing market-place that is driven by connected devices and phones, we will be discontinuing our Weather Direct Forecasting Service to all WA- and WD- Devices effective August 31st, 2017.

device We apologize for any inconvenience that discontinuing service on your Weather Direct station will or may cause. Current Weather Direct users should have received an email notification of this as well, and a second email will be sent with more information on possible replacement items for your unit.

It is our goal to exceed your expectations in our products and in our customer service, and we are committed to making the transition from old to new as easy as possible for our customers.

Please feel free to contact us with any questions at http://www.lacrossetechnology.com/support/index/form/

Sincerely,

La Crosse Technology


*sigh* I really liked these units as you could connect multiple receivers to one internet-connected transmitter. My favorite was the WA-1440U 4-Day Talking Internet-Powered Wireless Forecaster where you could send it speech and it could read the news for example. You could even customize it with your name for example and the speech was extremely smooth and fluid.

I had 3 units around the house and it was nice to glance at them to see what the weather would be. They will be missed.

It would be so awesome if someone could reverse engineer the wireless protocol but that'd be pretty difficult now that its all shut down.

Friday, October 6, 2017

Ubuntu 17.04 screen redraw after coming out of standby

One of the things that is really annoying me is that the Ubuntu screen doesn't redraw itself properly when coming out of screen saver or when coming out of standby.

The screen is double buffered and one of the buffers doesn't get fully updated, so you get this horrible flashing/flicker effect.

So I have to take one of the windows and pull it up to the top of the screen to force a full screen refresh since it does that "zoom animation thing".

I wonder if it's worse because I run a dual monitor setup.


It's just kind of annoying as I hate anything that flickers. Just redraw that screen, baby!


I'm just running integrated intel graphics.

lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)

lspci -v -n
00:02.0 0300: 8086:0152 (rev 09) (prog-if 00 [VGA controller])
Subsystem: 17aa:308c
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities:
Kernel driver in use: i915
Kernel modules: i915

Saturday, September 30, 2017

TMS9918A added graphics mode 2 with 50 transistors

It's interesting to read up on the history of the TMS9918 and how they added the "super pattern graphics mode" aka Graphics Mode II with only 50 transistors. That allowed a full bitmap display to be generated with each color table byte setting a group of 8 pixels to have 2 colors out of 16.

Fascinating.



http://msx.hansotten.com/technical-info/tms9918/


The specific document being:

http://msx.hansotten.com/uploads/files/198x%20Super%20Pattern%20Graphics%20Mode%20(Mode%202).pdf

Sunday, September 24, 2017

Writing to both the Third Millenium Arcade Board and the Super Sprite.


I wanted to write to the Third Millenium Arcade Board and the Super Sprite, but there's just one problem: The Super Sprite has its addresses at $C0F0 and $C0F1.

You can write to those addresses just fine in machine language with STA $C0F1 but an AppleSoft POKE doesn't work the same.

Applesoft POKE actually executes a STA ($50),Y to address $C0F1, but that actually reads $C0F1 before it writes $C0F1. It's kind of counter intuitive that you would have a read when you're trying to write something, but that's the wacky design of the 6502.

That read has the side effect of resetting the TMS9918A address pointer so when it writes, the TMS9918 thinks you want to specify the low byte of the address pointer. Each time you write $C0F1 it resets that pointer so you never actually finish setting the high byte of address pointer.

So you have to resort to assembly language, and I poke a little routine into memory and then call it. STA absolute doesn't have the same problem as the STA ($50),Y register indirect mode and it will write to $C0F1 properly without reading it first.

This applesoft program is horribly unoptimized, I just wanted something that would work.

It you let it run for a few minutes it will display the following:

(hint: display the frameskip with F11, set the frameskip to 6 with F8/F9 and unthrottle with F10 to speed things up)

./mame64 apple2e -sl4 arcbd -sl7 ssprite










The simple routines I poke into memory and call:

4000: 2 writes to C0F1 to set an address, reading C0F1 first to make sure we reset the address register
     It's a register write if the second byte has the hi byte set.
4014: same routine as 4000
     It's an address write if the second byte has bit 6 set, bit 6 clear if just to read.
4028: write to C0F0, write DATA register
403C: read from C0F0, read DATA register

]CALL -151

*4000L

4000-   AD F1 C0    LDA   $C0F1
4003-   A9 0F       LDA   #$0F
4005-   8D F1 C0    STA   $C0F1
4008-   A9 87       LDA   #$87
400A-   8D F1 C0    STA   $C0F1
400D-   60          RTS   
400E-   00          BRK   
400F-   00          BRK   
4010-   00          BRK   
4011-   00          BRK   
4012-   00          BRK   
4013-   00          BRK   
4014-   AD F1 C0    LDA   $C0F1
4017-   A9 00       LDA   #$00
4019-   8D F1 C0    STA   $C0F1
401C-   A9 78       LDA   #$78
401E-   8D F1 C0    STA   $C0F1
4021-   60          RTS   
4022-   00          BRK   
4023-   00          BRK   
*L

4024-   00          BRK   
4025-   00          BRK   
4026-   00          BRK   
4027-   00          BRK   
4028-   A9 78       LDA   #$78
402A-   8D F0 C0    STA   $C0F0
402D-   60          RTS   
402E-   00          BRK   
402F-   00          BRK   
4030-   00          BRK   
4031-   00          BRK   
4032-   00          BRK   
4033-   00          BRK   
4034-   00          BRK   
4035-   00          BRK   
4036-   00          BRK   
4037-   00          BRK   
4038-   00          BRK   
4039-   00          BRK   
403A-   00          BRK   
*L

403B-   00          BRK   
403C-   AD C0 C0    LDA   $C0C0
403F-   8D 4E 40    STA   $404E
4042-   60          RTS   
4043-   00          BRK   
4044-   00          BRK   
4045-   00          BRK   
4046-   00          BRK   
4047-   00          BRK   
4048-   00          BRK   
4049-   00          BRK   
404A-   00          BRK   
404B-   00          BRK   
404C-   00          BRK   
404D-   00          BRK   
404E-   00          BRK   
404F-   00          BRK   
4050-   00          BRK   
4051-   00          BRK   
4052-   00          BRK   

Monday, September 18, 2017

Copy the Apple ii text screen to the Third Millenium Arcade Board

So I thought I'd see if I could copy the apple ii's text screen to the tms9918.

Once I've loaded the font into the tms9918 memory, I can just copy bytes from the apple ii's text screen to the tms9918's memory.

Yes, it's not optimized, because I was assembling it by hand with the CALL -151 monitor.

So to write bytes to the TMS9918, you write the low byte of the address to $C0C3, then the high byte with bit 6 set (so we add 64 or $40). We want to write to location zero, so that means writing a $00, then a $40 to $C0C3.

Now any bytes written to $C0C2 will go to that address and then auto-increment the destination address.

We use the routine at $FBC1 to calculate the address of the text line given in A. That clobbers A so we have to restore it. It stores the address in $28 and $29. We use LDA ($28),Y to access the text memory, then STA it to $C0C2. Keep going until we get 32 chars in the line CPY #$20, and then keep going until we've done 24 lines CPX #$18.

4030-   A9 00       LDA   #$00
4032-   8D C3 C0    STA   $C0C3
4035-   A9 40       LDA   #$40
4037-   8D C3 C0    STA   $C0C3
403A-   A9 00       LDA   #$00
403C-   AA          TAX   
403D-   8A          TXA   
403E-   20 C1 FB    JSR   $FBC1
4041-   A0 00       LDY   #$00
4043-   48          PHA   
4044-   B1 28       LDA   ($28),Y
4046-   8D C2 C0    STA   $C0C2
4049-   68          PLA   
404A-   C8          INY   
404B-   C0 20       CPY   #$20
404D-   30 F4       BMI   $4043
404F-   E8          INX   
4050-   E0 18       CPX   #$18
4052-   30 E9       BMI   $403D
4054-   60          RTS   

If you're wondering why it's multicolored, I was experimenting with the TMS9918 color table.



My uploaded font, with the characters from 0-127 copied to 128-255 and colored with the color table. The color table for the 32x24 mode 0 has 32 bytes total: a single color for 8 character patterns.





I think the crazy colors look cool. Distracting but kind of cool.

Sunday, September 17, 2017

Fun with TMS9918 fonts on the Third Millenium Arcade Board





So you have to upload fonts to the TMS9918 to get it to display anything textwise.

I came across this great thread about ti fonts by sometimes99er where he has put together a bunch of great fonts in gif format:

http://atariage.com/forums/topic/165697-fonts/

There was one font in particular that is near and dear to me: The classic Amiga font.

Let's see if we can get the Apple II Third Millenium Arcade Board's TMS9918 to display it.

First, I thought I'd use HTML5 and firefox to generate the DATA statements for Applesoft:

So we create a canvas, draw the 0236.chr.gif into the canvas, and use getImageData() to get access to the data and generate a bunch of DATA statements.






This HTML5 generates the following DATA statements.





and we paste this into mame's apple2 driver with SHIFT+Scroll Lock to enter it into our basic program:

and I choose background B = 4 and foreground F = 15 for white text on blue for that classic look.




Friday, September 15, 2017

Disassembling the VDPTEST program for the Third Millenium Enginnering Arcade Board

So I thought I'd have a look at what the VDPTEST program actually does.

Doing a PR#1 and LOAD VDPTEST and LIST gets me:



What you see the basic program do is to BLOAD VDPTST which goes to address $1000 (4096) and it will patch it with the proper io addresses for the slot number. So every occurrence of C0C0 and C0C1 will get patched.

It will CALL 4096 after the patching and it writes the entire 16K ($4000) of the TMS9918 with the value held in memory location $104C and then reads it back, comparing it to what's in $104C.

If it gets an error, it writes $00 to address $2000 (8192), but if everything is cool it writes $CC to address $2000 (8192).

What is complete BS is the error reporting in the basic program. It looks for error information at 8193, 8194, 8195 and 8196, but quite frankly I don't see where it's getting this information, because the assembly program just doesn't write those locations. There should be an STX $2003, an STY $2004 or something.

It'll tell you there's an error, but the information reported is bogus.

I kept trying to figure out what the CALL 768 does. The CALL 768 in the program is setup in the HELLO program on the disk. It just resets the apple video output on reset according to the REM remarks.






So for fun, I thought I'd patch it by hand with the monitor so it would send the proper values to the basic program if there were an error. There's nothing like changing those values by hand.

I tested it using the mame debugger and changing the values in the TMS9918 vram by hand to simulate a memory error.

What was really driving me crazy is that the basic VDPTEST program kept patching the addresses after I'd changed them. A little "175 GOTO 210" fixed that. I changed the instances of $C0C1 to $C0C3 and $C0C0 to $C0C2 to get it to run under mame 189.