Użytkownik "bat" <b...@m...com> napisał w wiadomości
news:np74k8$laq$1@gioia.aioe.org...
>
> To nawet nie o to chodziło. Myślę, że miał sprzedaż dużą i zachował się
> nieodpowiedzialnie w stosunku do klientów elektroników.

Nigdy nie mieliśmy dużej sprzedaży.

> Pewnie sobie
> myślał, żeby trzymali stary złom i go to nie obchodzi.

Dokładnie odwrotnie.
Zachowywałem zgodność z XT/AT bo miałem sygnały, że ludzie używają takich
komputerów w warsztatach i zależy im abym ich nie zmuszał do zmiany.
U jednego nawet byłem kilka razy i nawet wysłałem mu raz, czy dwa razy
program do sprawdzenia (czy działa pod XT) przed wypuszczeniem.

> Prawdopodobnie
> nie chciało mu się tego softu utrzymywać i się schował przed klientami
> elektronikami. I wyleciał z rynku programatorów i narzędzi dla
> elektroników za to postępowanie.

Nie zrezygnowaliśmy z tego rynku. Od 199? przygotowywaliśmy serię urządzeń
(programator EPROM, EEPROM, GAL, emulator EPROM, programator Atmeli
InSystem). Seria nazywała się TopLess bo urządzenia nie miały górnej części
obudowy (płytka z nadrukiem była obudową). Stworzyliśmy system przełączanych
pętli prądowych - z jednego COMa (zasilanie przełącznika pętli z COMa) można
było obsługiwać do 10 urządzeń z zapewnioną izolacją galwaniczną. Dwużyłowy
kabelek mógł mieć do 100m długości z zachowaniem prędkości 115200. Długość
połączenia (komputer w pokoju, a uruchamiany układ (energetyka) na hali) i
izolacja była ważna dla Emulatorów a chcieliśmy wszystko mieć tak samo.
Emulatory i programator InSystem zasilały się z układu, a programatory z
wtyczkowych zasilaczy 9V.

Wszystkie prototypy były gotowe i mieliśmy je oprogramowane tak, że kilka
aplikacji mogło chodzić na komputerze i każda gadała ze swoim urządzeniem
mimo, że wszystkie połączone do tego samego COMa i już, już mieliśmy się
pokazać z kompletem nowych urządzeń, ale ...... wstąpiliśmy do Unii.
Wyszło mi, że nie da się zapewnić wymaganej przez CE odporności na ESD dla
urządzenia bez góry obudowy no i kilka lat pracy poszło do śmieci :(.

Piccolo i Picco-GAL były zasilane ze złącza klawiatury więc naturalnie
wymierały (w 2003 sprzedaliśmy kilka sztuk (chyba bliżej 0 niż 10)).
Przeprojektowywanie TopLessów na NieTopLessy nie miało sensu, bo już było
jasne, że teraz jest era USB i nie byliśmy do tego absolutnie przygotowani.

> Znalazłem pliki. To nie były 2 lata ale 5 lat przerwy.
> Totalne olanie nas wszystkich. Prawdopodobnie poprawił kilka linijek i
> skompilował. Draństwo.
> Jak znajdę starszy to w hex edytorze porównam...


> 07.01.99 Poprawa błędu programowania 89C4051.
> v 4.77
>
> 13.09.04 Rezygnacja z kompatybilności procedur komunikacji RS232
> v 4.78 z komputerem XT (może też AT) aby zapewnić pracę pod Windows'XP.
>

Gdyby ta zmiana była związana nie tylko z Windows XP ale też z
wcześniejszymi Windowsami na pewno znalazła by się o tym wzmianka w tym
pliku.

Tobie wydaje się wszystko takie proste.
Jakiś 1.5 roku temu napadli mnie ludzie, że napisany przez mnie w 1995r
Assembler 8051 nie działa pod Windows 10. Ja pracuję pod Windows XP. Nie mam
dostępu do komputera z Windows 10. U mnie tamto exe działa. Co z tym zrobić.
Program napisany pod DOS, exe z 1995r przekompilowane Turbo C++ 1.0.
Wygrzebałem (z trudem) źródła z 1995r. Wtedy w 1995 mnie coś napadło, że
koniecznie muszę (ambicja) zrobić ten assembler jako jednoprzebiegowy.
Szybko się okazało, że na komputerze z 640k RAMu np. assemblacja programu do
DSM-51 już wymagała 70% dostępnej pamięci. Udało mi się zwiększyć maksymalną
długość assemblowanego programu (o około 25%) dzięki przeciążeniu operatora
new.

Najpierw przepuściłem źródła przez Turbo C++ 1.0. Wszystko przeszło i
uzyskałem działający u mnie exe.
Uznałem, że może chodzi o to, że system jest 64 bitowy. Czyli muszę to
przekompilować jakimś nowym kompilatorem. Zainstalowałem sobie Buildera
2010.
Ale moje źródła, za żadne skarby nie chciały się przekompilować. Wszystkie
moje stringi mu się nie podobały, a assemler to praca na stringach -
wszystkie mnemoniki, parametry typu rejestry itd. Poległem. Nie jestem
programistą (programuję tydzień/dwa tygodnie w roku). Od innego użytkownika
tego Assemblera dowiedzieliśmy się jak obejść problem i przekazaliśmy temu
pierwszemu i u niego też zadziałało.
Pół roku temu pojawiła się znów.
Tym razem spróbowałem pod Builderem 5, który znam lepiej. Ten nie miał nic
przeciwko moim stringom. Ileś rzeczy musiałem zmodyfikować i w końcu się
przekompilowało, ale próba uruchomienia i access violation. Nie jestem na
tyle biegły aby umieć namierzyć taki błąd. Stwierdziłem, że pewnie to moje
przeciążenie new daje o sobie tak znać. Uznałem, że muszę ten assembler
napisać od nowa. Wydrukowałem wszystkie źródła i zacząłem je czytać - no nic
nie pamiętam, a jest tego kilkadziesiąt stron. Napisanie od nowa oceniłem na
2..3 miesiące. No nie mam tyle czasu.
Wróciłem do tego access violation. Już nie pamiętam, ale w końcu jakoś
metodą prób, błędów udało mi się znaleźć przyczynę problemów. Główny problem
był taki, że w Turbo C++ int miał 16 bitów a w Builderze 32 bity. Wydawało
by się, że jak więcej bitów na zmienną to nic złego się nie może stać, ale
może. Przejrzałem wszystkie użycia int w programie. Się okazało, że to co
uzyskałem działa pod Windows 10. Ale dlaczego - pojęcia nie mam. Przecież to
jest program, który tylko działa na plikach. Tu nie może być mowy o braku
dostępu do UARTów jak w przypadku Piccolo. Nie przekompilowałem go też na 64
bitowy.
P.G.